Continuous Integration fundamentals
Software only becomes valuable when you ship it to customers. Before then it’s just a costly accumulation of hard work and assumptions.
DARRAGH CURRAN
What is Continuous Integration?
The Continuous Integration approach is designed to create an automation environment ensuring that every change to the application results in a releasable version, and that any version can be built automatically at the push of a button. At a broader level, Continuous Delivery aims to make the entire end to end release process of that application hands free (automated) where the built application (from Continuous Integration system), is delivered frequently to the testing and then production environments. The goal of the Continuous Delivery cycle is to ensure consistency and high quality by delivering fast user centric feedback. Continuous Integration is an important subset of Continuous Delivery.
The goal of Continuous Integration is to automate traditionally manual stages in the application development process in which a feature complete version of the software is moving for the first time from development to the system integration and integration testing phase.
But wait, What's the difference between Continuous Integration, Continuous Delivery and Continuous Deployment
Continuous Integration
is the practice of integrating changes from different developers in the team into a mainline as early as possible, in best cases several times a day. This makes sure the code individual developers work on doesn’t divert too much. When you combine the process with automated testing, continuous integration can enable your code to be dependable.
Continuous Deployment
is closely related to Continuous Integration and refers to keeping your application deployable at any point or even automatically releasing to a test or production environment if the latest version passes all automated tests.
Continuous Delivery
is the practice of keeping your codebase deployable at any point. Beyond making sure your application passes automated tests it has to have all the configuration necessary to push it into production. Many teams then do push changes that pass the automated tests into a test or production environment immediately to ensure a fast development loop.
What are the available tools? how to choose between them ?
There are many solutions out there. If you only want to get a list of tools, you can look at Jenkins, TravisCI, SemaphoreCI, CircleCI, Codeship, Bamboo, Teamcity or many others. You can also find many articles and discussions out there on the topic with valuable information like this one on Quora. There are almost endless opportunities out there. But then the question rises: “How to choose between these?”
Your pick will strongly depend:
- on your requirements,
- on the techstack you have and
- on how you handle your daily workflow.
Benefits and Advantages of Continuous Integration and Deployment
Continuous Integration has many benefits. A good CI setup speeds up your workflow and encourages the team to push every change without being afraid of breaking anything. There are more benefits to it than just working with a better software release process. Continuous Integration brings great business benefits as well.
Reduces Risk
If you test and deploy code more frequently, it will eventually reduce the risk level of the project you are working on as you can detect bugs and code defects earlier. This means they are easier to fix and you can fix them sooner which makes it cheaper to fix them. This will speed up the feedback mechanism and make your communication much smoother.
Better Communication
When you have a CI process in place that is hooked into a Continuous Delivery workflow it’s easy to share your code regularly. This code sharing helps to achieve more visibility and collaboration between team members. Eventually this increases communication speed and efficiency within your organization as everybody is on the same page, always.
Faster iterations
As you release code often, the gap between the application in production and the one the developer is working on will be much smaller. Your thinking about how to develop features most probably will change. As every small change will be tested automatically and the whole team can know about these changes you will want to work on small, incremental changes when developing new features. This results in less assumptions as you can build features quicker and test and deploy them automatically for your users to see as soon as possible, thus gaining valuable feedback from them faster.
Faster feedback on business decisions
Having a CI process is not only beneficial for software developers, but for their managers as well. Both parties can gather valuable feedback and gain insights much faster. As you push code more often, you have more data available which you can analyze to check if the product is heading into the right direction. This continuous data flow and the timeline of metrics (like dependency, unit tests, complexity, and code smell) can also help to reflect on the progress of the project more frequently which enables faster technological and business decisions.
You can read more about CD/CI benifits on this blog
Deep dive into CD & CI
A key principle of a Continuous Delivery approach is that the application is always production ready. This means that all artifacts required to build the application are stored and managed in a version control system, and that code must be consistently and regularly checked in to the source mainline to ensure small increments between builds. Basically, the code in mainline is expected to be continuously production ready. There are three important and foundational elements that underpin any Continuous Integration System.
- Commitment to building tests: The first is one of the most important elements; the commitment of the development team to produce a comprehensive test suite at the unit level and functional level together with their code. This is essential to achieve the “guaranteed” level of code quality that can be production ready at any moment.
- Never break the build: The goal is that the application must be ready to be built, packaged and deployed on every committed change. This (of course), means that broken or untested code should never be
committed. - Version Control: Another foundational element to Continuous Integration is version control. To be ready to focus on implementing Continuous Integration, the code has to be managed by strict version control
policies.
When the code is always production ready, managed by strict version control policies, and the development team has adopted an agile development and unit testing practice, organizations can move to implement a Continuous Integration environment.
Each distinct stage in the Continuous Delivery blueprint can be then implemented to complete the Continuous Delivery workflow. Below is a sequence diagram explaining the suggested flow of steps in a Continuous Delivery workflow.
With Continuous Integration, applications are built from a very early stage in the development process at specific frequent intervals or on every change checked in by the developers. This effectively eliminates the need for integration testing and the cost associated with developers spending time on this phase. The enablement of frequent incremental builds and mandating a comprehensive automated testing process also allows developers to detect problems early and as a result, ensure higher application quality.
To illustrate a typical Continuous Integration workflow, consider the following scenario:
- During the development of the application, the developers are working on their local machines and once they are ready to submit their new code changes they commit them to the central source code repository. In the diagram below the Source Control Management (or version control) system is a Git repository.
- When the code is checked in to the mainline (or the release manager merges code changes from one of the developers), the new code addition to the main branch triggers a new release.
- The Continuous Integration system monitors the version control system for changes and launches the build process.
- The Continuous Integration server gets the source code from the repository.
- The Continuous Integration server runs unit tests to validate the quality.
- The Continuous Integration server packages the files into distributable units and deploys the package onto a test server and validates the package and basic functionality by running automated functional tests.
- The Continuous Integration server deploys the same package on the testing environments for thorough user acceptance testing.
- Once the acceptance tests are successful the same package is deployed on the production servers. Implementing
infrastructure and release automation enables end to end automation and allows provisioning and deploying the
application packages on all servers with a click of a button.
Conclusion
Continuous Delivery is a methodology, a mindset change and a leadership practice that focuses on how to achieve rapid application delivery throughout the software application lifecycle. This relies on the adoption of automation to streamline manual processes and enforce consistency and repeatability in the software delivery pipeline, as well as enhanced collaboration and shared metrics and processes across Dev and Ops teams.
One of the fundamental requirements for establishing Continuous Delivery is the implementation of an automated Continuous Integration system that automatically and consistently builds the application from code components and resources to a deployable package.
Sources: