Continuous Integration: Pros, Cons, Best Practices, and Why You Need to Start Now

What is Continuous Integration?

Continuous Integration (often referred to as CI) is a development methodology with the goal of supporting frequent changes to code in a manner that produces reliable, high-quality results. Developers follow a process of making small frequent changes into a common main branch. It generally includes automated tests to help prevent errors from being introduced. This empowers the development team to identify and fix bugs more quickly, because the changes tend to be more incremental and less complex than they would be with less frequent integration.

CI is designed to mitigate the risks traditionally associated with updating code in large infrequent releases and can make software organizations more nimble and adaptable.

This empowers the development team to identify and fix bugs more quickly, because the changes tend to be more incremental and less complex than they would be with less frequent integration.

How the Process Works

Developers write a new feature or fix a reported bug on their development machines and then push their new branch to a collaborative repository. Automated unit and integration tests run and notify the team of potential new bugs or other code quality issues. Assuming the automated tests pass, the developer creates a pull request (aka PR). A PR allows developers and reviewers to comment directly on the changes the developer submits to the main branch. Most  PR tools support convenient inline dialog about the proposed changes.

Upon completing the review process and merging the new code into the main branch, the feature development and bug-fix cycles continue from the integrated main branch. This often happens several times a day, especially for a large team with everyone working on many small tasks, and it means that everyone is working on the same common code base. Divergence of the code, and the associated problems that can arise from feature developers being out of sync with each other are significantly reduced.

Why Aren’t All Teams Doing Continuous Integration?

Continuous integration is the industry standard for efficient development. However, if your company or product started before CI was a common standard, you may have a legacy process. It’s worth the effort to explore implementing this DevOps best practice in your business.

Challenge 1: Up-front Investment

Before you can start your team on continuous integration, you’re going to need two things – tools and training. This isn’t a step you can just insert into your typical development process without teaching your team how to move forward effectively or preparing them with the CI tools they’ll need in their day-to-day tasks. Arming your team with the knowledge they need and setting aside time not only for initial training but for ongoing training can be costly for some organizations.

It is possible that some in the industry have made this out to be more of an issue than it actually is. If done correctly (see our best practices below), implementing continuous integration can cost significantly less than you may think. We argue that adopting continuous integration is a solid investment in your development team and business as a whole. While you will need to pay a little up front, you’ll almost certainly save much more than the initial investment in tools and opportunity cost over time.

Challenge 2: Internal Resistance

Not all developers want to spend valuable time relearning processes. They want to complete their work without getting caught up in what they may perceive as bureaucratic procedures. If your team is resistant to this kind of change, you probably have some work-culture challenges to deal with. However, the best practices we’ve outlined below should help.

Challenge 3: Frequent Code Commits

For developers who work on large chunks of code, breaking their tasks up into smaller pieces to make the necessary frequent code commits can feel frustrating at first. A good trick to overcoming this is to put everyone in the reviewer position at one point or another. When you think about committing your code for the benefit of the reviewer, it can help you organize things into cohesive commits, rather than just doing slash-and-burn changes to get something working without ever reflecting on your commit history.

Organizing your code and your commit messages as if they’re a form of communication does take a few extra moments of consideration before opening a PR, but it will make you more organized and will earn you the respect of your peers.

Challenge 4: Choosing a Testing Method

With more frequent code pushes come more frequent testing. Continuous integration calls for automated testing, which catches some bugs. However, it doesn’t remove the critical step of manual testing. Many teams can struggle to keep up with the needed daily testing. Some may be tempted to forgo daily testing and only conduct testing periodically (e.g. once a week or when full features get completed). But those who want to avoid long QA backlogs need to figure out how to manage ongoing testing. Once you form the habit, you’ll probably wonder how you ever lived without it.

Continuous Integration Benefits

Benefit 1: Faster Bug Fixes

Frequent code pushes paired with ongoing automated testing delivers fewer bugs. It also makes pinpointing issues easier, because the diffs are less complex. This makes QA leaner and faster and reduces issues over the long-term.

Benefit 2: Stronger Code That Inspires Team Confidence

Continuous integration also reduces the anxiety of pushing a ton of code at once – you don’t have to imagine a million things going wrong and then tracking down the source of each issue. By making small, frequent commits, every developer can have a close eye on their changes and any problems that arise from them.

Benefit 3: Encouragement of Rapid Application Development

Fewer bugs (and quickly-resolved bugs) means faster application delivery. You can deliver to key stakeholders faster, giving users new or changed functionality more frequently. CI sets up your business for more flexibility.

Benefit 4: Increased Efficiency and Productivity

Continuous integration, therefore, makes your team more productive and allows you to plan more frequent updates. Your team can build more nimble software, unburdened by weighty code commits and bugs. Testing gets lighter and takes up fewer hours for the team as well. They can focus more on adding new features and less on QA.

Benefit 5: Increased Automation Overall

This process encourages teams to shift many processes to their preferred CI tool – not just testing but also builds and pipeline management. This enhances the quality of your code and end product and makes your team lighter and more flexible.

Continuous Integration Best Practices

Having considered the pros and cons, it’s time to decide if it’s the best time to adopt continuous integration within your organization. My team and I serve as a development partner for our clients, and we take this process for granted. If your organization’s projects are in “deployment hell,” it is probably time to consider some changes.

If you decide your team should adopt continuous integration, we recommend you embrace the following best practices:

1. Make Sure It Makes Sense

Echoing the point made above, don’t shift all of your development processes toward CI at once. It will almost certainly benefit your business in the long haul. There can be growing pains, so focus on planning well. Run the numbers to see what it would take to get you up and running, and make sure time and budget costs project a solid return on investment for not just your team but also your company.

2. Gain Collective Buy-In

If your developers aren’t on board, you’re going to have a tough time making continuous integration work, even with a well-laid plan. I recommend sitting everyone down and thoroughly discussing the challenges and benefits of the changes they’ll need to make. Answer everyone’s questions and make it a collaborative effort. Inspire your team to build a plan for adoption and get their feedback on CI tools to put under consideration.

3. Build a Strategic Roadmap

You can’t just install a few tools, go through the basic motions with your team, and then make a shift in one day. We suggest outlining a transition for your organization – what project team should serve as a beta test to work out the kinks? Consider starting with a low-impact project to minimize risk.  Plan your shift strategically and slowly. Establish organization-wide standards, and share these across your teams to promote buy-in.

4. Train Your Team

Don’t forget about training your teams. They may need some help understanding how things work in the real world and will need practice in handling issues as they arise. Your developers may need guidance on how this works and the alterations they’ll need to make to their daily activities, especially if they’re used to much bigger, less frequent code commits. It can be a good idea to designate one or more gurus and/or evangelists to whom teams can turn for support when they get stuck.

5. Manage a Single Source for Your Code

To maintain revision control, your team should make all pull requests to a central branch. Yes, you will still use branching, but focus on getting all branches merged back onto the main branch as often as possible. Make sure that production hotfixes get immediately merged back into all upstream branches to avoid unintended forks. Prune dead branches frequently. Avoid clutter. Use semantic versioning and make consistent version tags whenever you release code to production. This reduces the number of competing versions of your software and makes QA much easier for your team.

6. Choose Tools You Can Trust

If you don’t feel good about your tools, you won’t feel good about the software you build, let alone the process that gets you there. Build a list of potential tools with your team and then fully explore each one to see what fits your culture and specific needs best. CI is best facilitated by a DVCS (distributed version control systems) such as Git, because DVCS systems are designed for easier merging. If you’re still using a traditional VCS like SVN or CVS, you’ll probably want to tackle the transition to a DVCS like Git as a first step. A DVCS of course also requires a collaboration server for PRs, such as BitBucket or GitHub.

Popular CI tools include Jenkins, Bamboo, TeamCity, TravisCI, and GoCD, but there are many more out there on the market to explore. Here at Soliant, we are very happy with a suite of Atlassian tools and use BitBucket for PRs and Bamboo for CI on closed source projects. We use GitHub for PRs and Travis for CI on open source projects. There are subtle usability differences between tools, but generally, the widely adopted ones are a safe bet and will get the job done. You should pick the tools that work best for your situation.

7. Don’t Leave for the Day Without a Commit

Leaving changes on a local machine at the end of the day is a recipe for disaster. Everyone on your team should PR their code at the end of the day to the main repository to minimize merge conflicts. Yes, this can make for awkward breaks, but you must adopt daily code commits for this to work. If your work is really not ready to merge, consider prefixing a PR title with “WIP – DO NOT MERGE”. The main thing is that you’ve pushed and PR’d. Taking this practice seriously will help developers gain confidence in the system.

8. Make All Work Visible

Everyone should have visibility into the changes every developer makes to the code. This allows them to understand how others’ changes will affect their own and proactively fix any potential code conflicts. At any point in time, every team member should be able to see the most recent build, all present bugs, and what’s in the pipeline.

Learn More About Our CI Experience

To get a more comprehensive look at continuous integration best practices in action, contact our team. We’re happy to share insights about our process and how it’s evolved over the years.