In this model, we explain the definition of Continuous Integration and its relationship with Continuous Deployment and Continuous Delivery, and how these processes occur.
When we are done with the preliminaries, we explore further the intricacies of these systems and their workflow.
What is Continuous Integration?
According to Techopedia, Continuous Integration (CI) is…
“Continuous integration (CI) is a software development practice in which each member of a development team integrates his work with that produced by others on a continuous basis.”
Software developers often work in isolation and therefore the advent of CI is a great practice when working in a team because prior to the emergence of Continuous Integration, it took days or even weeks for software developers to integrate their code and also to merge changes from different branches of code. These long periods of time created many merge conflicts, stubborn bugs, code strategy divergence and duplicated effort. CI requires the team’s code be merged to a shared control branch, continuously, to avoid these problems.
Principles of Continuous Integration
The principles of CI according to Codeship are:
1. The maintenance of a code repository
2. Automating the build process
3. Making the build self-testing
4. Everyone committing to the baseline every day
5. Every commit to baseline should be built
6. Keeping the build fast
7. Testing in a clone of the production environment
8. Make it easy to get the latest deliverables
9. Everyone can see the results of the latest build
10. Automatic deployment
How Does Continuous Integration Work?
- Developers input code into their private terminals.
- After that is done, they commit the changes to the shared repository.
- The CI server monitors the repository and analyzes changes as they occur.
- Continuous Integration builds the system and runs unit and integration tests.
- The server also releases deployable artefacts for testing.
- The CI server assigns a build tag to the version of the code it just built.
- The Continuous Integration server gives the team reports of the successful build.
- If the build or tests fail, the server alerts the development team.
- The team will fix the issues as soon as is possible.
- It continues to integrate and run tests throughout the entire project.
Why Employ Continuous Integration?
While developing software you have so much available to you in terms of languages, test suites, frameworks and so many features offered by CI. You may choose the language you are most comfortable with, choose the test suite you deem most suitable and you might even choose not to use a framework at all but instead ensure that you always employ this practice.
This development practice has been known to improve the quality of code without giving developers extra work. A great example of this in action is up for download at ITTSystems.com, with it you clearly see how the testing and checking of code is controlled by the CI server and results are automatically conveyed back to you.
These are our top 9 reasons why we think you should always employ CI and why you ought to make it part of your project from the very beginning.
1. Run Your Tests of Code in the Real World
As we all know, there are times when your code testing has given the green light when run on your machine but when tested on someone else’s, the test might fail. Well, with Continuous Integration, such embarrassing occurrences can be avoided. You can run your code to your new branch and the Continuous Integration server will take care of running the tests for you. If everything is fine, you can be sure that you didn’t break the code. And if the code fails on another person’s machine, you have evidence that your code is not at fault.
2. Boost Coverage of Code Tests
Very often you might think that your tests cover most of you code, well think again! A CI server can check your code to be certain that the test covers all aspects fully.
With this development practice, you can be sure that your code tests are thorough, especially highlighting when you commit a change to your code without testing. The continuous integration server will notify you of any reduction in your coverage, as a percentage. This can act as the “conscience” for your coding activities.
3. Automatic Code Deployment
The Continuous Integration server can automatically deploy your code to production environments after ensuring that all the tests within a particular branch are passed. This process is what is known as Continuous Deployment. This stage is usually very gratifying for all software developers.
4. Instant Build Processes
After all your codes tests have been passed and code test coverage is great, CI servers can also activate build and compilation processes that will satisfy your needs as quickly as possible. No need to be rooted in front of your workstation waiting for the build to be complete, only to have it fail at the last second. The Continuous Integration server will run this process for you, using its scripts, and give you a report if anything goes wrong.
5. Simultaneous Procedures
With equivalent build support, you can divide your code tests and build processes, and set them up to run on different machines or terminals. This means that the entire procedure will be completed even quicker than if you ran it locally on one machine. It will also consume less local capacity and resources, which means you can keep working on other things while the build processes run.
6. Decline in Breaks
Continuous Integration servers test your code in newly created branches to prevent the master build from getting broken by committed changes that have not quite passed the tests. This ensures your code is tested thoroughly before merging it into the master build, which if broken can be frustrating.
7. Decrease Code Review Time
Your CI server and Version Control Server can be made to communicate with each other and inform you when a merge request is good to go. It can also demonstrate how code coverage would be affected by the merge. This can radically decrease the amount of time it takes to review a merge request.
8. Easier Faster Detection of Bugs
Continuous Integration does not remove bugs from code but will noticeably increase the detection of bugs which enables them be removed.
9. Build Repeatable Processes
In today’s world, based on rapid innovation, it is imperative that development teams deliver high-quality software faster than their competitors. Modern development teams are building proficient software delivery engines by creating repeatable processes that regulate the best development practices. With automated testing, your code is tested via the same process for every change you commit, so you can rest assured that every change is tested before it is deployed to production.
What Is The Difference Between Continuous Integration And Continuous Deployment?
Continuous Integration and Continuous Deployment (CD) are very closely related but there are slight differences in the detail.
The CI process is more focussed on the quality of code and making sure that it passes all testing before being merged into the master build while Continuous Deployment is focussed on the master build being functional in the real world.
Let us think about this using the analogy of a car assembly line where CI ensures that the individual parts are of great quality and that the parts are installed properly, while CD ensures that the assembled car itself is efficient.
If you have Continuous Integration and Continuous Deployment implemented successfully, the translation between the two should be flawless because the entire process can be triggered by anyone at the push of a button.
Continuous Integration and Continuous Delivery
The only difference between Continuous Delivery and Continuous Deployment is the presence of the automated push to production. Continuous Integration requires a manual push to production while CD makes that step automatic.
CI Tools
One of the necessities for the execution of Continuous Integration is the use of CI tools, also known as build servers. There are numerous CI tools out there but just a few are often chosen due to availability and consumer’s choice. Picking the right development tools for your purposes can be a bit tedious, especially if you are using them for the first time. Your pick will strongly depend upon:
- On your requirements,
- On the techstack you have, and
- On how you handle your daily workflow.
Here we introduce a few of the more popular tools:
1. Jenkins
Jenkins is categorized as a Java written, open source, cross-platform tool. Its configuration is done both through a GUI interface and via console commands. The platform is free and its flexibility is based on its feature extension through a wide range of plugins, which you can easily add to. In addition to being extendable, Jenkins can also distribute builds and test loads on multiple machines. It is published under a MIT license hence the freedom to use and to distribute.
2. Teamcity
Coming from JetBrains lab is another awesome CI server, TeamCity. In its free version, this platform is great because it provides support for a wide variety of tools and frameworks and since it supports many .NET features out of the box, you may want to take a closer look at it while contemplating your next .NET project.
Although TeamCity is a Java based solution, its builders deserve a thumbs up for having multiple means of customization and integration. For example, you have the options of creating plugins via an open API or a REST API. Although the free version is quite spectacular, with the build agent licence, you can get an additional build agent in addition to ten build configurations. If that isn’t enough you get even more if you go with the enterprise version.
The following list, compiled by www.Dzone.com, will supply you with a quick and easy preview of the features and capabilities of some of the most used CI tools on the market.
Travis is one of the more popular open source services and is free for all open source projects that are hosted on the GitHub. Seeing as it is hosted, it does not rely on any particular platform. This service is organized using .travis.yml files which possess the information of what to do. It supports a large number of languages and the build setting for each of them is well documented. Travis makes use of virtual machines to build applications. If a user has private storage or needs to run two or more jobs simultaneously, there are a variety of monthly subscriptions plans that give a user access to this feature.
GoCD is the latest Cruise Control creation from ThoughtWorks and is free of charge to most users. However, the commercial support or help system that ThoughtWorks offers is only available to its paid users. It is supported on Windows, Mac and a number of Linux distributions. The reason GoCD is different from a lot of other CI tools is due to its concept of a pipeline, which simplifies the modelling of a complex build. The pipeline concept is quite helpful to Continuous Delivery and is comparable to the Jenkins pipeline. Using GoCD’s value stream map, users are able to visualize their end-to-end workflow in real time.
GitLab CI is a development tool born out of the open source Rails project GitLab, which was produced by the company GitLab Inc. GitLab is a free hosted service supported by GitLab.com. It offers intricate git storage organization with certain features such as code reviews, issue tracking, access control and many more. GitLab CI is completely incorporated with GitLab and it can effortlessly integrate into projects by utilizing the GitLab Application Program Interface. Due to the fact that GitLab process builds are written in the Go language, they can run on FreeBSD, OSX, Windows, Docker and Linux. The tool can run numerous projects concurrently and possesses integral Docker support. GitLab CI offers two editions, which are the open source GitLab Community Edition and the GitLab Enterprise Edition. Both editions come with a 45 day money back guarantee.
CircleCI is yet another hosted alternative that comes from the GitHub Company. Currently CircleCI offers support to only GitHub and the list of supported languages includes PHP, Java, Skala, Python, Node.js, Ruby/Rails and Haskell. What makes CircleCI different from other tools is that their services are offered via “Containers”.
The Container is the main pricing block for CircleCI. One container is offered free of charge and a user is allowed to build as many projects on it as they want. Additional containers come at a fixed price and with a varying degree of parallelization which a user chooses based on their preference or needs. There are five levels, or types, of parallelization on offer 1, 4, 8, 12 and 16. Therefore, a user who starts off with 16 containers will achieve optimum parallelization of 16 on just one build. The amount of containers a user requires for one build is entirely up to them. CircleCI supports Docker as well.
There aren’t too many hosted solutions and Codeship is one of the more popular hosted Continuous Integration tools available. Codeship depends on BitBucket and GitHub and offers some test parallelization with a feature like ParallelCI. This tool supports Ruby(Rails), Node.s, Go, Java, PHP and Python and a user can deploy projects on such services like Heroku or AWS. The trial part includes one synchronal build and one parallel test pipeline, but allows just 100 builds per month and only 5 projects. The pricing is based on the numerous package upgrades with the choice of adding the Docker platform for a supplementary cost of $75 per month. There is also a customized plan where you can fully modify parameters to suit your team.
Hosted Versus Non-hosted Continuous Integration Tools
Choosing a CI tool can be a bit tricky, first you want to ask yourself the question, “what platform would be most convenient for me considering the time and available resources, SaaS or self-hosting?
Self-Hosted Continuous Integration Tools
There’s no doubt that self-hosted CI servers are now seen as old school but let’s face it they still have some pretty interesting qualities and some of these are features that cannot really be outsourced. Old time users will be quick to point out that with self-hosted servers; you have total control over your entire build process. Most of the well-known continuous integration servers have a huge list of potential plugins and extensions, and users can also write some of their own if they wish.
How about the ability to provision your CI server? Here’s the thing, if a user chooses to employ a configuration management tool such as Peforce or Puppet, they can utilize the tool to condition the server itself. The primary advantage of doing this is that it makes sure that the Continuous Integration server is conditioned the same way as the production machines. This implies that the packages installed on the CI server will complement the versions of packages on the production machines. This means it can spot hidden bugs that only come into sight under some very particular configurations.
Here’s the catch if you’re going to be doing it yourself, it’s a bit difficult and quite time consuming. If your organization lacks the necessary resources to dedicate to configuring a CI server properly and ensuring it is kept running virtually every second of the day, they will certainly experience down time. Keep in mind that the server is closely linked to the development workflow and therefore if it is not working properly it will affect productivity of the development team and the organization at large.
Hosted Continuous Integration Tools (SAAS)
Hosted CIs on the other hand are fun to work with as all the heavy lifting has been done for you. You don’t need to bother about spending time and resources building from scratch as all you have to do is decide which framework you want and then build on that, or for the more popular frameworks, grant them access to your source code. Some may consider this risky but the way around this is to work with companies who have an established track record.
What this means is that in a matter of minutes, you can have a functional CI server as opposed to a matter of days that it would take you if you were to go the old school route and do it yourself. It goes without saying that if speed is one of the things you enjoy when you should go with a hosted CI.
The decision to maintain a scalable test infrastructure that is capable of rendering support to a variety of languages and technologies is one that won’t come without its share amount of work and stress for your team. These challenges include constant updates, unexpected problems with the test server and provision of support for different versions.
The obvious way around this would be to outsource the maintenance of your test infrastructure. In this way your engineering team can focus their time and resources on building the actual product. The reality of all this is that SaaS products will naturally grow to support more technologies, which is actually their core purpose.
Additional Features of A Hosted Continuous Integration Tool
If you are choosing a hosted CI tool then you need to consider the following features, which are deemed obligatory for implementing a successful process.
1. Connectivity
Even though GitHub is one of the most popular tools, it is well known that not all projects can utilize it. Seamless integration with Github or Bitbucket is important as it would make code delivery super easy.
2. First Time Setup
Creating a build server can be a tedious and slow process, especially if your project is complex. Building a prototype project to create the CI might be easy, but until your real world project is working, you are not quite finished with it. It is expected that a Continuous Integration tool offers guidance to the user through the first steps in the project setup.
3. User Interface
Getting a build system through its first steps is just the beginning. If you are working on several projects at your continuous integration terminal, you will definitely require a means via which you can monitor and control them. Usually, such projects demand the need for a dashboard that can organize build reports and provide other functional navigation links.
A good interface is hard to define seeing as different people prefer different things, however, one can instantly recognize a bad interface that prevents you from accomplishing your task.
The least that should be expected from a user interface of a development tool is one that gives the user an overview of all their builds and allows them to explore each build for more details.
4. Build Environment
This is the most important aspect that highlights the functionality of a continuous integration tool. It includes the various programming languages supported by the product, the versions of compilers available, the build systems and the ease of updating or installing new software. A tool gets better reviews if it has extensive configuration properties and allows the user to define the build environment in an intuitive manner.
5. Feedback
After setting up a build, there are a number of faults or errors that could take place, ranging from incorrect environment configuration to failed unit tests or even unresponsive external services etc.
Many users want to have real-time monitoring of their builds and consistent logging of anything that went wrong. A tool might even be able to permit the ssh connections to the build servers, which is a very good feature to possess, especially when the build behaves in an unpredictable manner.
6. Post-Build Steps
After completion of the build, the user might need to do handle the results by deploying the artefact to a staging server, sending an email, uploading it to FTP, updating a bug issue or anything else that fits in with their processes. A Continuous Integration tool receives high scores in this respect if it offers several post-build hooks to allow a user to take advantage of the build output and is even better when it supports integrations with specific cloud providers like Amazon, Microsoft, Rackspace and Navisite.
