Continuous integration is easy. Download Jenkins, install, create a job, click the button, and get a nice email saying that your build is broken (I assume your build is automated). Then, fix broken tests (I assume you have tests), and get a much better looking email saying that your build is clean. Then, tweet about it, claiming that your team is using continuous integration.
I’ve seen it multiple times in multiple projects. The start is always bright and smooth. Problems start later when the build gets broken again and we simply don’t have time to fix it. We’re simply busy doing something else and a few broken unit tests shouldn’t be a distraction for us. After all, we all know that unit testing is not for a team working with deadlines, right?
Wrong. Continuous integration can and must work. The latest build should always be clean. Always.
What is Continuous Integration?
Nowadays, software development is done in teams. We develop in feature branches and isolate changes while they are in development. Then, we merge branches into master (Git usage is assumed). After every merge, we test the entire product, executing all available unit and integration tests. This is what is called continuous integration, abbreviated as CI.
Sometimes, some tests fail. When this happens, we say that our “build is broken”. Such a failure is a positive side effect of quality control because it raises a red flag immediately after an error gets into master. It is a well-known practice, when fixing that error becomes a top priority for its author and the entire team. The error should be fixed right after a red flag is raised by the continuous integration server.
# Why Continuous Integration Doesn’t Work?
CI is great, but the bigger the team (and the code base), the more often builds get broken. And, the longer it takes to fix them. I’ve seen many examples where a hard working team starts to ignore red flags, raised by Jenkins, after a few weeks or trying to keep up.
The team simply becomes incapable of fixing all errors in time. Mostly because the business has other priorities. Product owners do not understand the importance of a “clean build” and technical leaders can’t buy time for fixing unit tests. Moreover, the code that broke them was already in master and, in most cases, has been already deployed to production and delivered to end-users. What’s the urgency of fixing some tests if business value was already delivered?
In the end, most development teams don’t take continuous integration alerts seriously. Jenkins or Travis are just fancy tools for them that play no role in the entire development and delivery pipeline. No matter what continuous integration server says, we still deliver new features to our end-users. We’ll fix our build later. And it’s only logical.
# What Is a Solution?
The solution I propose is simple — prohibit anyone from merging anything into master and create scripts that anyone can call. The script will merge, test, and commit. The script will not make any exceptions. If any branch is breaking at even one unit test, the entire branch will be rejected.
In other words, we should raise that red flag before the code gets into master. We should put the blame for broken tests on the shoulders of its author.
Say, I’m developing a feature in my own branch. I finished the development and broke a few tests, accidentally. It happens, we all make mistakes. I can’t merge my changes into master. Git simply rejects my push, because I don’t have the appropriate permissions. All I can do is call a magic script, asking it to merge my branch. The script will try to merge, but before pushing into master, it will run all tests. And if any of them break, my branch will be rejected. My changes won’t be merged. Now it’s my responsibility — to fix them and call the script again.
In the beginning, this approach slows down the development, because everybody has to start writing cleaner code. At the end, though, this method pays off big time.
In my projects I automate this merging operation using www.rultor.com, a free hosted DevOps service. Its usage is explained in this article: Rultor.com, a Merging Bot. I would be glad to answer your questions, just shoot me an email.
funny i ran into this just now. we (HP) have been developing a solution which works just like that and we will make it open source soon.
Gabby we would love to hear more about this one. Reach out to me if you like to discuss
the process i had used for many years is to merge master to the branch, run integration cycle (build and test, gatekeeper review), then push to master. just as you describe. for teams that have granular repositories, this will be much easier to pull off. for large teams with monolithic code repositories, there will be an integration bottleneck. although this sounds like an easy workflow to migrate to, for most teams it takes a fair amount of work, as the tooling typically is not there to support this workflow. for example, if a developer needs to integrate, and merge from master to branch, along with build, test cycle, it takes too long, getting buy-in for this workflow is slim-to-none if speed is not there. my approach was to refactor codebases, refactor build systems, get everything to build and test, distributed and in parallel, aiming for 10x speed improvement. there are many factors that contribute towards bottleneck at integration, resulting in each team requiring different tactics to improve speed and integration quality.
First, you should say that this post is sponsored.
Testing before commiting to master seems to be a good idea and Microsoft calls it “gated check in”. It is possible to implement this feature with others automatic build tools that are not TFS.
And CI def is not dead.
Akira, first you should know this post isn’t sponsored. In fact none of our posts are sponsored. You can’t sponsor posts on staging-devopsy.kinsta.cloud, we accept submissions from a wide range of people and views to facilitate discussion in the community.
Now that that is out of the way, you point is one that has been brought up before. I think the author here was trying to make a point and his provocative title isn’t really the point of the article if you read it. Feel free to write and submit a full response and we will try to publish it
alan shimel
CI is dead?
So your solution is using CI…!
We use GitLab with GitLab_CI
Developeres cannot commit under Master… they do a branch, do there changes, commit and push… but will have to create a Merge Request under GitLab!
CI will run builds and tests under that branch and if OK and Assignee gets 2 OK from reviews he can do the Merge! 🙂
Master is always complie clean and ready for client delivery!
? for sensationalist headline
The author does not seems to be having fair idea about continuous integration methodologies and best practices, however that should be fine. What is not fine is passing judgement as “this does not work” simply based on half-cooked stories and inexperienced know-how.
Not sure how he concluded about merging to master first and then running all tests .. sounds funny based on industry practices. There are foolproof ways to prevent master code from build breakages, by running whole unit-test and automation-tests in private branches before pushing the code to master branch, so that the master remains always clean.
One could not push until all unit-test and automation passes. This is how CI works and it rocks!!
Read more .. http://www.yegor256.com/2014/10/08/continuous-integration-is-dead.html
This is gaining traction and people are surprised about the quality of articles staging-devopsy.kinsta.cloud is publishing !
Yeah but technically, this is not continious integration anymore (because you do not integrate into the _master_ continually) but pretty much what yegor describes (just running the ‘script’ on a CI server).
stated problem: ci gets hard as teams get too large
solution: don’t let teams get too large OR don’t let projects and their code get too large.
no software management process or philosophy can solve the stated problem in and of itself. this has nothing to do with continuous integration.
In traditional approach we never check the code for the errors until project has done completely, but in Continuous integration allows agile software development teams to check the code frequently to detect the problems, if any errors detected development team fix the errors in that iteration itself.
So if it is continuous integration, why we only associate Jenkins with it? We have so many others platforms to do the job better than Jenkins.