Target release 2019-M1 Epic Document status Document owner Gajendran C (Unlicensed)

• The relevant terms here are "Continuous Integration" and "Continuous Deployment", often used together and abbreviated as CI/CD .
• Continuous Integration simply means that you run your "integration tests" at every code change
• Continuous Delivery simply means that you "automatically deploy" every change that passes your tests.
• However recently the term CI/CD is being used in a more general way to represent everything related to "Automated build pipelines" from where a developer commits until that code ends up in customer env. 

GIT         

Build     

 Deploy

Test      

Visibility 

Without a doubt, automated test are the most important part of any CI/CD pipeline. Let me repeat that since it's so important: without proper automated tests that run fast, have good coverage, and no erroneous results, there can be no successful CI/CD pipeline. It's that simple.

The automated tests are usually divided into multiple "suites", each with their own objective. The list below gives a small overview.

• Unit tests. This is the suite that is run first, often by developers themselves before they add their changes to the repository.
• Unit tests normally test individual classes or functions. When those classes or functions need access to external resources, those resources are often faked as "mocks" or "stubs".
• Integration tests. This is the next level up from unit tests. Integration tests make sure that the modules that comprise an application work properly with each other.
• Ideally integration tests are run in environments to make sure that if your application uses a database that the same database is available in your integration environment.
• System tests. Should test the entire system (e2e) in an environment as close as possible to the real production environment.

Note that because software development is such a young craft, there's sometimes different definitions that are being used for these phases Also there's other type of tests that are sometimes relevant like performance tests or user interface tests. Nevertheless, the three types of tests above (unit, integration and system) should form the basis for the vast majority of CI/CD pipelines.

Test Environments

In addition to a quality tests, it is also important to take care of the environments where they run. The following are important:

• Clean environments. It is very important that your tests are run in clean environments, otherwise there may be interference between different test runs. Ideally the entire test environment is reset before a test run using whatever technology available, for example virtual machine snapshots.
• Fidelity. In order for the test results to mean anything, they should run in an environment that is as close to your production as possible.
• Ideally test environments can be spun up and down quickly and are allocated on-demand. This gives the lowest cost and the highest throughput. Hosting these environments in the cloud is therefore ideal.

Recommendations

I hope this blog post was a useful introduction to CI/CD. If you are considering implementing CI/CD then we need the following:

• Focus the software development on small incremental change rather than big breaking changes. Break bigger changes down in smaller ones.
• Invest in creating an automated test suite. Do this incrementally as it's too big to do it all at once. But don't stop until you have good code coverage (> 90%).
• Once you have some tests in place, start setting up the automation for your pipeline.
• Use feature toggles or canary deployments to gradually expose your user base to a new feature, rather than your entire base at once.

Some other benefits of using CI and CD

• Reduces overhead across the development and deployment process
• Reduces the time and effort for integrations of different code changes
• Enables a quick feedback mechanism on every change
• Allows earlier detection and prevention of defects
• Helps collaboration between team members so recent code is always shared
• Reduces manual testing effort
• Building features more incrementally saves time on the debugging side so you can focus on adding features
• First step into fully automating the whole release process
• Prevents divergence in different branches as they are integrated regularly
• If you have a long running feature you're working on, you can continuously integrate but hold back the release with feature flag.