CI/CD, quick guide for PM’s

The reason why I wrote this article is that there are a lot of Project & Product Managers in IT that are not technical. Despite this fact, at least little technical background can drastically improve their competencies. If you are a Software Engineer, QA Tester, Solution Architect or DevOps Engineer, do not waste your time reading this. However, if you are a Project Manager without any technical background, and you do not have basic knowledge about DevOps, Continuous Integration & Continuous Delivery topics, then this post is for you. Let’s the knowledge party begin!

Why should we care about Continuous Integration & Continuous Delivery?

The are plenty of benefits of using Continuous Integration & Continuous Delivery, like:

1. Quicker life cycle and faster product deployment — everything is automated. It works a bit like an assembly line, where you put chunks of code, and the CI is assembling and testing everything together. Due t the shorten product development life cycle we have faster product deployment. That makes incremental code changes tested and deployed
2. Stable production-ready code — incremental changes are going to be merged into one, single code repository. Then the automated build is triggered, and automated tests are run. At this point, we are in a situation, when with just one click we can deploy our software on production. Going even further, we can automate this process, which will take us to Continuous Deployment. The tested code is ready for production. Since we are focused on incremental changes and testing software from the very start, we see a decrease in integration and testing time
3. Consistent and repeatable build process — Adopting the CI practice can also lead to increased code testing coverage. Continuous integration applications can report test coverage. Because of automated testing, we see a decrease in manual testing and bug fixes. Bug fixes are reduced because we have automated unit and integration tests. We have got those tests automated right in our build. Therefore more bugs are detected before production deployment. At the point we integrate the code, we fire off that build process.
4. Improved code quality and better testing coverage — Continuous Integration is the consistent and repeatable build process. It follows standardized industry best practices. Moreover, automated testing validates and verifies code readiness and the code quality

Some basic info about Continuous Integration, Continuous Delivery and Deployment

So, Continuous Integration is a software development practice, until which:

1. The small code changes are integrated frequently. It can be done daily or even several times a day. Developers usually merge small, incremental code changes which are tested in an automated manner, and ready to deploy on production,
2. Shared, single code repository is used,
3. Each code commit initiatives a build process, and;
4. During each build, automated tests are launched to test the code correctness.

Continuous Integration is concerned with the build process and integration stage of the software release cycle. Do not miss out on CI with the Continuous Delivery process. Continuous Delivery is concerned with continuous delivering the production-ready code. Those can be new features, bug fixing, improvements, experiments or developed user stories.

Once the changes have passed the automated tests in CI, the build is ready to be deployed in the production environment. But remember, it is ready to be deployed, however, it is not deployed yet. It gets us to the point when we have a one-click deployment. If relevant stakeholders choose, we can deploy the software on the production with just one click.

In the above notes, we mentioned Continuous Delivery. Do not mismatch it with Continuous Deployment. Continuous Deployment involves automatically deploying ready software to the production environment. We do not have a one-click deployment any longer. The whole process is automated from the very beginning up to the end.

How to start with Continuous Integration and Continuous Deployment?

The Developers or DevOps Team must:

1. Set up code repository. They can choose GitHub, Bitbucket, or any of the others version control programs,
2. Choose a suitable Continuous Integration and Continuous Delivery service, which can automatically run our builds, and trigger the automated tests whenever a commit was done. It can also deploy the builds if it is required,
3. Create and configure automated tests that will run when our build will be triggered.

What kind of tests do we design for Integration Tests?

We can distinguish several types of tests to be done in CI:

1. Module or Integration Tests — are run to confirm, that the whole product works after new code chunks were deployed. The different components of the product must work together so that our product is still functional,
2. Performance tests — those tests are designed to test the non-functional requirements,
3. Unit Tests — tests the sources code created by developers. The tests particular, isolated code chunks.

What are the tools available for Continuous Integration & Continuous Delivery?

We can distinguish:

1. Internally hosted tools,
2. Cloud-based CI/CD tools,
3. Open Source, proprietary, custom solution,
4. Usability, cost, learning curve, reporting capabilities
5. Integration with other tools in your code development tool-chain. Security, data storage and retention.

If you have any questions, do not hesitate to ask!