Continuous Integration and Continuous Delivery

CONTINUOUS INTEGRATION:

In Automation Continuous Integration (CI) and Continuous Delivery (CD) are popular software development practices for automation and shortening feedback times.

Continuous Integration is a software development practice in which developers integrate, build, and test their work frequently, typically supported by automation. Each integration cycle happens on a Continuous Integration Build Server, which performs the following seven steps, in order:

1. Detect changes in the source code repository tool. Subversion is an example of a source code repository tool.

2. Extract the source code changes from the source code repository tool and move them to the Continuous Integration Build Server.

3. Compile the source code changes.

4. Perform quality validation–related tasks such as running automated unit tests and performing automated architecture verification, design validation, and code quality analysis. These tasks are optional in the Continuous Integration process, but they are strongly recommended as enforcing quality as early in the process as possible is a key attribute of the Continuous Architecture approach.

5. Check the new compiled code back into the Source Code Repository tool.

6. Report build status to designated stakeholders.

7.Optionally package and deploy successfully integrated code to the testing environment.

The Continuous Integration process is depicted at a high level in picture.

Continuous integration is a software development practice where members of a team integrate their work frequently. Usually each developer integrates at least daily. Each integration is verified by an automated build involving the running of all automated tests that should detect integration errors as quickly as possible. Martin Fowler defines practices for continuous integration7: 1. Maintain a single source repository. The source repository should include code and tests.

2. Automate the build. The system should be able to be built by checking the source out of the repository and issuing a single command.

3. Make your build self-testing. Include automated tests as part of the build process.

4. Everyone commits to the mainline every day. Developers should not “secretly” develop their code in a sandbox which enables them to keep their latest code out of the build, possibly creating more and more integration problems over time.

5. Every commit should build the mainline on an integration machine. If the mainline build fails, the problem should be fixed right away rather than waiting for the nightly build.

6. Keep the build fast. If the build is not fast, developers will commit less often and will be provided feedback on problems less often.

7. Test in a clone of the production environment. Testing in a different environment introduces risk when the system is deployed in production.

The main benefit of continuous integration is reduced risk of integration problems. Additionally, regression and integration bugs can be found and fixed more rapidly.

CONTINUOUS DELIVERY:

Continuous delivery is a software development practice that uses automation to speed the release of new code.

It establishes a process through which a developer’s changes to an application can be pushed to a code repository or container registry through automation.

How is continuous delivery related to CI/CD?

Continuous delivery makes up part of CI/CD, a method to frequently deliver software by automating some of the stages of app development. The "CI" in CI/CD refers to continuous integration. With continuous integration, new code changes to an app are regularly built, tested, and merged into a shared repository. It’s a solution to the problem of having too many branches of an app in development at once that might conflict with each other. The “CD” in CI/CD can refer to continuous deployment or continuous delivery, which describe ways to automate further stages of the pipeline.

Continuous integration Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch. Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch. Continuous delivery Continuous delivery

Is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage. This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button. In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

Continuous deployment Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production. Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a "release day" anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it. How the practices relate to each other To put it simply continuous integration is part of both continuous delivery and continuous deployment. And continuous deployment is like continuous delivery, except that releases happen automatically.

Benefits of each practice: We've explained the difference between continuous integration, continuous delivery, and continuous deployments but we haven't yet looked into the reasons why you would adopt them. There's an obvious cost to implementing each practice, but it's largely outweighed by their benefits. Continuous integration What you need (cost)

• Your team will need to write automated tests for each new feature, improvement or bug fix.

• You need a continuous integration server that can monitor the main repository and run the tests automatically for every new commits pushed.

• Developers need to merge their changes as often as possible, at least once a day.

What you gain

• Less bugs get shipped to production as regressions are captured early by the automated tests.

• Building the release is easy as all integration issues have been solved early.

• Less context switching as developers are alerted as soon as they break the build and can work on fixing it before they move to another task.

• Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.

• Your QA team spends less time testing and can focus on significant improvements to the quality culture.

Continuous delivery What you need (cost)

• You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase.

• Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn't be a need for human intervention.

• Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production.

What you gain

• The complexity of deploying software has been taken away. Your team doesn't have to spend days preparing for a release anymore.

• You can release more often, thus accelerating the feedback loop with your customers.

• There is much less pressure on decisions for small changes, hence encouraging iterating faster.

Continuous deployment What you need (cost)

• Your testing culture needs to be at its best. The quality of your test suite will determine the quality of your releases.

• Your documentation process will need to keep up with the pace of deployments.

• Feature flags become an inherent part of the process of releasing significant changes to make sure you can coordinate with other departments (support, marketing, PR...).

What you gain

• You can develop faster as there's no need to pause development for releases. Deployments pipelines are triggered automatically for every change.

• Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.

• Customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year.

Summary:

Continuous integration is a way to perform stable and frequent deployment of high quality. As Martin Flower said, “Frequent deployment is valuable because it allows your users to get new features more rapidly, to give more rapid feedback on those features, and generally become more collaborative in the development cycle”. Continuous integration is a way to remove the wall between companies and their customers, creating client-oriented, useful software.