What exactly is continuous integration and how can it impact your dev team? Read on to learn the basics of continuous integration and why it is done.
Developing software can be immensely rewarding, but at the same time it can also be terribly chaotic.
In any software development project there are numerous interconnected elements to build, control, and consider, as well as various areas and people whose roles and responsibilities overlap with each other. Such has caused many development teams to grapple with a slew of issues.
But there is a way to untangle such a mess: Continuous Integration.
Continuous Integration is a coding philosophy and set of practices that drive development teams to implement small code changes, and frequently merge such changes into a shared version control repository. It is a DevOps best practice that allows dev teams to more frequently and reliably deliver code changes.
Why Go with CI?
Normally when developers make changes to the code of an application, they take a copy of the code base to work on and once done with their changes, submit the changed code to the source code repository. This would be fine if you only had one or a few developers working on the code, but in many cases there will be several developers working on the same code base and adding new code.
You can start to see how this would cause problems. With several developers submitting changed code, the copy eventually ceases to reflect the original repository code. As well as changing the code, developers may be adding new code, libraries, and other resources that create dependencies, and consequently potential conflicts. The longer developers work on a branch before merging, the more changes may occur in the repository. When they do decide to submit code to the repository, they must first make sure to update their code according to the changes made to the repository since they took their copy. The more changes there are, the more work developers must do before they can submit their changes.
With all these going on, the risk of multiple integration conflicts is high, and the time it takes to integrate changes greatly exceeds the time it took to make changes to the original code. Because of this, developers find it difficult to ascertain the time of delivery on feature requests. Code gets released at a much slower pace with a higher risk of failure, and these risks only grow as the size of the team and the codebase increase.
And the problems don’t end there. Developers must manually coordinate and communicate when they contribute code, not only to each other but to operations and the rest of the organization since many others may be affected by the changes they made. If you have an offshore software development team or outsource software development, you could have communication gaps here due to time and location differences between your organization’s teams. All these result in time costs, communication overhead, and unnecessary bureaucratic costs.
How Continuous Integration Works
When applied successfully, CI effectively solves all of these issues. Essentially, it is as its name suggests: the continuous integration of code changes from various contributors to one single software project. CI allows software developers to work on features independently and in parallel, and once done they can quickly and independently merge these features to the end product.
With CI you have a consistent integration process in place, which leads developers to commit code changes more often. Defects and other software quality issues are detected more easily due to the smaller size of code submitted, and the chances of developers working on the same code are slim. Overall, the result is better collaboration and software quality.
Establishing CI entails several parts and steps. It starts with a version control system or VCS. Some of the most popular VCS are Git, Subversion, and Mercurial. Along with the VCS, a version control hosting platform is needed. Examples of these are Github and Bitbucket, which already have features and support for CI.
Once version control is set up, integration approval steps are added. Probably the most important among these steps is to add automated tests to the project. This will require the installation of a testing framework, and test code and test cases which are to be written by the developers. There are also other approval mechanisms you can use, such as code style formatters and syntax checkers. Some teams use feature toggles or feature flags, which are configuration mechanisms that can turn features and code on or off during run time. This can be useful for wrapping and turning off features that are still under development. Other teams opt for version control branching, which uses a branching strategy to define protocols for merging new code into standard branches for development, testing, and production. This approach however, can be difficult to manage if there are a number of different features being developed at the same time.
Once the version control system has been set up and merge approval steps are in place, CI is officially established.
CI Best Practices
Achieving CI successfully also requires the application of best practices. These include:
- Test Driven Development – CI is intended to be used alongside automated unit testing, and it is best practice to constantly improve the test coverage. Test Driven Development or TDD is a practice that helps to ensure this. It is the practice of writing out test code and test cases prior to any actual feature coding. The product team can be involved in this practice by providing expected specifications or requirements, which the development team can then turn into test cases.
- Pull Requests and Code Review – Most development projects already practice a pull request and code review workflow, and these are considered critical to a CI pipeline. A pull request is normally made by a developer to notify other developers that he or she has made new changes to the code which are ready for integration. In a CI pipeline, a pull request is an opportune moment for signalling automated approval steps, and perhaps an additional manual approval step that can include a code review. Together, this is a powerful practice that fosters passive communication and knowledge sharing among all the developers within the team.
- Build Automation – In CI it is best practice to have one command capable of building the entire system. There are already several build tools in existence, such as make, and many of these are frequently used in CI environments. Ideally, build automation should include automating integration, including deployment into a production-like environment.
- Optimize and Prioritize Speed – It is essential to optimize the execution speed of the CI pipeline, as any delay could compound exponentially as the rate of feature releases, team size, and codebase size increase. Speed is also key in quickly identifying and resolving any problems that may come up during integration. It also allows developers to push changes quickly and experiment with different feature ideas that could improve the product performance and user experience.
Benefits of Continuous Integration
As you may have already surmised, CI offers plenty of benefits. Among them are:
- The quick, early, and easy detection of integration bugs due to the smaller change sets.
- A current build is always readily available for testing, demo, or release purposes.
- Scaling team size, codebase size, and infrastructure is more easily achievable.
- There is a faster feedback loop, meaning that product teams can test ideas and iterate product designs faster, and changes can be quickly pushed and measured for success.
- CI enhances communication, accountability, and collaboration not only among the development team but with the rest of the organization as well.
- Frequent, automated testing is done and generates software metrics which can guide developers in developing functional, high quality code.
Continuous integration is only the first phase of an automated software release pipeline, which includes continuous delivery (CD) and continuous deployment. Together, these ensure that developers are able to push changes frequently without issues and with greater stability. Any development team looking to scale and/or improve their current operations would do well to implement a CI/CD pipeline, but must be sure to reach a consensus regarding the right approaches for their business and technologies so CI/CD practices can be applied consistently.
