CI (Continuous Integration)
Continuous Integration describes the process of the changes flows to the repository. Let’s take a look at a simple schema that gives an example of team development.
A source code version control system is the crux of the CI process. The version control system is also supplemented with other checks like automated code quality tests, syntax style review tools, and more.
The majority of CI processes can be described according to this algorithm.
On each Pull Request opening (and pushing new changes as well) Git server sends a notification to the CI server.
CI server clones the repository, checkouts to the source branch (for instance, bugfix/wrong-sorting), and merges with the master branch.
Then the build script is being launched. For example, ./gradlew build.
If the command returns 0 code, then the build is successful. Otherwise, it’s treated as the failed one.
CI server sends the request with the build result to the Git server.
If the build is successful, then the Pull Request is allowed to merge. Otherwise, the merge is blocked.
The process guarantees that any code that goes to the master branch does not break the further builds.
CD(Continuous Delivery)
Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.
Our goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.
The practices of continuous delivery help us achieve several important benefits:
Low risk releases. The primary goal of continuous delivery is to make software deployments painless, low-risk events that can be performed at any time, on demand. By applying patterns such as blue-green deployments it is relatively straightforward to achieve zero-downtime deployments that are undetectable to users.
Faster time to market. It’s not uncommon for the integration and test/fix phase of the traditional phased software delivery lifecycle to consume weeks or even months. When teams work together to automate the build and deployment, environment provisioning, and regression testing processes, developers can incorporate integration and regression testing into their daily work and completely remove these phases. We also avoid the large amounts of re-work that plague the phased approach.
Higher quality. When developers have automated tools that discover regressions within minutes, teams are freed to focus their effort on user research and higher level testing activities such as exploratory testing, usability testing, and performance and security testing. By building a deployment pipeline, these activities can be performed continuously throughout the delivery process, ensuring quality is built in to products and services from the beginning.
Lower costs. Any successful software product or service will evolve significantly over the course of its lifetime. By investing in build, test, deployment and environment automation, we substantially reduce the cost of making and delivering incremental changes to software by eliminating many of the fixed costs associated with the release process.
Better products. Continuous delivery makes it economic to work in small batches. This means we can get feedback from users throughout the delivery lifecycle based on working software. Techniques such as A/B testing enable us to take a hypothesis-driven approach to product development whereby we can test ideas with users before building out whole features. This means we can avoid the 2/3 of features we build that deliver zero or negative value to our businesses.
Happier teams. Peer-reviewed research has shown continuous delivery makes releases less painful and reduces team burnout. Furthermore, when we release more frequently, software delivery teams can engage more actively with users, learn which ideas work and which don’t, and see first-hand the outcomes of the work they have done. By removing the low-value painful activities associated with software delivery, we can focus on what we care about most—continuously delighting our users.
When should we run CD jobs? Triggers may vary.
Deploy after each Pull Request merge.
Deploy according to the schedule.
Deploy after each Pull Request merges to the particular branch.
Combined option.
CI/CD Tools
1. Bitbucket Pipelines: Bitbucket Pipelines is a CI tool directly integrated into Bitbucket, a cloud version control system offered by Atlassian. Bitbucket Pipelines is an easy next step to enable CI if your project is already on Bitbucket. Bitbucket Pipelines are managed as code so you can easily commit pipeline definitions and kick off builds. Bitbucket Pipelines, additionally offers CD. This means projects built with Bitbucket Pipelines can be deployed to production infrastructure as well.
Features :
Easy setup and configuration
Unified Bitbucket experience
Cloud by 3rd party
2. Jenkins: Jenkins is a veteran CI Tool with a long proven track record. It is open source and driven by community updates. Jenkins is primarily intended to an on-premise installation. Jenkins is a great option when your organization needs on-prem support for handling sensitive customer like HIPAA compliance data.
Features:
On-premise
Open source
Robust addon / plugin ecosystem
3. AWS CodePipeline: Amazon Web Services is one of the most dominant cloud infrastructure providers in the market. They offer tools and services for all manner of infrastructure and code development tasks. CodePipeline is their CI Tool offering. CodePipeline can directly interface with other existing AWS tools to provide a seamless AWS experience.
Features:
Fully cloud
Integrated with Amazon Web services
Custom plugin support
Robust access control
4. CircleCI: CircleCI is CI Tool that gracefully pairs with Github, one of the most popular version control system cloud hosting tools. CircleCi is one of the most flexible CI Tools in that it supports a matrix of version control systems, container systems, and delivery mechanisms. CircleCi can be hosted on-premise or used through a cloud offering.
Features:
Notification triggers from CI events
Performance optimized for quick builds
Easy debugging through SSH and local builds
Analytics to measure build performance
5. Azure Pipeline: Azure is Microsoft’s cloud infrastructure platform, the Microsoft equivalent to Amazon Web Services. Like the aforementioned AWS CodePipeline, Azure offers a CI Tool that fully integrated into the Azure suite of hosting tools.
Features:
Azure platform integration
Windows platform support
Container support
Github integration
6. GitLab: Gitlab is a new CI Tool which offers a full DevOps experience. Gitlab was created with intentions to improve Github’s overall experience. Gitlab offers a modern UX with container support.
Features:
On-prem or cloud hosting
Continuous security testing
Easy to learn UX
7. Atlanssian Bamboo: Another CI offering from Atlassian. Whereas Bitbucket Pipelines is purely a cloud hosted option, Bamboo offers a self hosted alternative.
Features:
Best integration with Atlassian product suite
An extensive market place of add-ons and plugins
Container support with Docker agents
Trigger API for IFTTT functionality
Advantages:
Speed of deployment
Faster testing and analysis
Smaller code changes
Better and faster fault isolatio
Increased code coverage
Automatic deploy to production
Never ship broken code
Process is repeatable
Faster mean time to resolution
Smaller backlog
Improved customer satisfaction
Tons of open source tools available
Disadvantages:
New skill sets must be learned
Steep learning curve to implement automation
Big upfront investment
Legacy systems rarely support CI/CD
High degree of discipline and dedication to quality
Difference Between CI and CD
Continuous Integration | Continuous Delivery |
CI is the process of integrating code into a mainline code base. | CD is the processes that have to happen after code is integrated for app changes to be delivered to users. |
CI is done using platforms designed specifically for the purpose. | Those processes involving testing, staging and deploying code. |
Implementing CI is as simple as using the right tools | CD is more complicated. These processes takes different forms depending on the culture of the team and type of app it is creating |
The Tech Platform