Continuous Integration, CI
Continuous Integration CI is a software development practice where members of a team integrate their work frequently into a shared repository, usually each person integrates at least daily — leading to multiple integration per day. — Martin Fowler
Let’s break down the above definition of CI by taking a look at some keywords.
Software development practice — This involves the application and putting into consideration, practices which when applied can lead to the delivery of quality software.
Team Integration — This involves a group of software developers, committed to delivery of software perhaps for an organization or a client. Each member of the team has to work together on maybe different modules to make up the sum of the software application.
Multiple integration per day — The members of the team, from the above definition, are required to make commits into the project, everyday. How and where do they make the integration? On a Version Control System like Git. Why? So as to keep track of changes to the source code of the application over the daily integration/commits.
How Continuous Integration Works
Firstly, code for the application been built is on a shared repo accessible to the team of developers. Code written by members of the development team is then committed to the shared repo. The automated CI server, then builds the system, runs unit tests, ensuring that the changes made by the developer(s) do not break the app. If it does break the app, the server shows where the test failed, so the developers can fix it immediately – and integration continues.
The key take away for CI is that developers don’t have to manually check for where a break in the code occur – this is handled by the automated CI server – thus, saving time that would have been spent in debugging.
The Principles and Practices of Continuous Integration, CI
For effective practice of CI, software teams should adhere to the following structure.
- Shared Repository — Members of the team should maintain a single repo for the project. Everyone on the team is expected to know where the repo to get the source code for the project is. This require you to implement a Version Control of your choice like Git. It implies that there should be a solid branching strategy, and branches for fixes.
- Commit to the mainline everyday — The mainline is the current state of the system. Thus, developers are expected to make daily commits-integrations-
- Automate build process — A build involves all the necessary factors like compilation, needed to for the successful execution of a program. This involves an automated way of ensuring that broken builds are fixed immediately, and this helps to fasten the build process.
- Automate the test process — There should be written tests,automated to ensure that code integration is passed when committed or fixed, should the test fail.
- Everyone has access to the latest results and can see every changes made by any member of the team.
- Daily commitment and integration by everyone to the mainline.
- Deployment process should be automated.
Benefits of Continuous Integration, CI
- High quality software resulting from fixing of bugs immediately.
- Quick delivery of software, as bugs are detected early and fixed, leading to a reduction in technical debt
- Automation reduces issues with the product
- Effective and improved communication between team members
- More flexibility as a result of short integration
- Satisfied clients and happy users
Continuous Delivery, CD
Continuous delivery, CD is a software development practice where software can be deployed into production at any time. It is highly dependent on Continuous Integration, and should not be confused for Continuous Deployment — the automatic deployment of software into production all the time.
The Principles and Practices of Continuous Delivery, CD
- CD is highly dependent on CI, thus you should have Continuous Integration in place
- There should be a collaboration between development team and operations, DevOps
- The deployment process and test acceptance should be automated.
- Create a delivery pipeline. Deployment should be tested and this can be accomplished through the configuration of a deployment server and running of tests.
- Delivery of the software should be on-demand
Benefits of Continuous Delivery, CD
- Fast delivery as it requires less effort
- Reliability in release of product
- Businesses have absolute control of releases
- Quick feedback loop
- Better quality software
A brief look at some CI and CD tools
There a collection of tools that you can choose from, which can help you with CI and CD. There are open source tools and proprietary tools, self hosted and in the cloud tools. We will just take a look at a few of these tools.
- Jenkins — is the leading open source automation server. Written in Java, it can be used as a simple CI and CD server. What’s more? It has comprehensive list of plugins, free to use and is cross platform.
- Teamcity — is an enterprise level CI and CD server from JetBrains. It offers free features of up to a 100 build configurations and 3 build agents.
- Travis-CI — For every open source project on GitHub, synced to Travis CI, you can always test your code in minutes for free! It prides itself as the home of open source testing. Some of it’s features include — live build views, pull request support, auto deployments on passing builds.
- Bamboo — Is a proprietary software from Atlassian, owners of Jira and Bitbucket. Bamboo helps teams handle continuous delivery from code to deployment. It automates builds, tests and releases in a single workflow.
- GitLab CI and CD — A proprietary CI and CD tool from GitLab, helping teams to build, test, deploy, and monitor code. Some of its features include cross platform, flexible pipelines, docker support, auto-scaling. It is open source as part of the GitLab Community Edition and the proprietary GitLab Enterprise Edition.