CI/CD Pipeline Architecture

Abstract

In this article, we are doing to discuss how CI/CD pipeline architecture and its E2E journey, which inclusive of integrating Unit testing and code coverage.

Architecture

CI/CD Pipeline Architecture

Please find the below stakeholders who are involved while setting up CI/CD pipeline.

  • Development Engineer
  • DevOps Engineer
  • Architect

Agenda

  • Why do we need CI/CD pipeline
  • What it gives as an outcome.
  • Configuration Setup Hook ( Deployment Group, Build and Release)
  • How to integrate Unit Testing and Code coverage report in the Build pipeline.
  • Why do we need Manual Deployment for Upper Environment?

Why do we need CI/CD pipeline?

In today's environment, everything we are expecting is a fastened approach, so why do we need to wait a long duration for deployment? Also, we are doing Automation in Testing, Why can't apply the same approach in the Deployment cycle? That's the triggering point here, so the CI/CD means Continous Integration and Continuous Deployment. It implies, once the code is committed, the system will automatically kick-start the build, do unit testing, and finally deploy into the respective environment accordingly without manual effort. We need to do a few setups to work on this, however, it's not that much hard to set up. I would like to recommend applying CI/CD while starting the project itself, if it is Greenfield development and for brownfield development, we need to allocate separate tasks or time for the same. 

What it gives as an outcome

It's not a testable task as user story development, so don't expect to create a development and testing task while working on this feature. It is automation work, where you are reducing manual work and speeding up our day-to-day activities, where we do need to wait a long pace to get released in the server or a few extra follow-ups to deploy or make sure deployment is done in the server. We can implement this in a couple of methods. Firstly try to create it in the initial environment, maybe if you have a development integration environment then please do it, otherwise, start with QA, once you are happy, then clone it in different stages with the respective configurations. 

The outcome of this CI/CD pipeline is 

  • Deployment in all Server once the user committed the code., All server means, maybe in Dev you have only one server, however, QA may have three servers, so make sure, artefacts are deployed in all configured servers. If any server is missing, then please check the deployment group configuration. 
  • Able to initiate unit testing or snapshot testing, which suppose to get successful, otherwise build suppose to fail.
  • Getting Code coverage report
  • We can see the build pipeline result, as the list of items is done while the build pipeline finished. 
  • In the build result, we have a designated tab, which lists out Unit test cases and code coverages. 

Configuration Setup Hook

Please make sure a few configurations while setting up CI/CD pipeline as step by step

  1. Deployment Group: This is the place where we need to set up or register your server machine to understand where we need to push the artefacts.
  2. Build Pipeline: You have a couple of options, where we can write it as YAML script, otherwise, go with the classic wizard approach. It's up to you, which one you prefer.
    1. Consume a Pool which relates to your project.
    2. npm, build, to build your artefacts
    3. npm test, make sure you have this command in your package.config file
    4. makes sure you use jest and coverage package to do your unit testing and generate coverage report. 
  3. Release Pipeline: This is the area, where we need to configure the following items
    1. Consume the respective artefacts
    2. Configure the deployment group according to the environment
    3. Setup whether you want to make it a Continous Deployment or Manual Deployment
    4. Create an Application pool if required and try to avoid the creation of an app pool for React or angular-based applications.
    5. Configure variables and get those variables according to the environment while doing the deployment.
    6. Finally, make sure runs once the deployment is done. 

How to integrate Unit Testing and Code coverage report in the Build pipeline.

This section is optional, however, I would like to recommend here, keep this as a mandate in your project. Initially, it may be a bit cumbersome work, however, eventually, it gives a lot of benefits when we see it in the long time run. We can utilise this module for our regression testing in future. Try to apply this task as a skeleton, while kick starts your project because whoever works on this project, will look into this, then they also try to apply it in their own modules. So it's easy to proceed, instead of re-inventing the wheel later point in time. 

You can consume whichever test package suits you, I used enzyme, jest and JUnit for testing and code coverage reports. 

The code coverage is one which says how much code covered from your unit test case, this gives an idea about what are modules you covered and which may not, so this gives an idea about do you want to cover anything extra or if it's good to go ahead.

Also recommended approach in the unit test case, please try to focus on your modules instead of the whole application.

Why do we need Manual Deployment for Upper Environment?

This is applicable to security concerns and processes, Typically we segregate as a couple of environments which as lower and higher. The lower environment is one where the developer has access end to end, and the upper environment is the one which may be a black box for a developer or read-only access. 

Basically, we need this process, to add a third-party eye while we do anything. In UAT, staging and Live, usually the deployment team has full control, so while kick starts deployment in this environment, as per process we need their consent to push the artefacts in the respective servers because they are the one who has a lot of ownership on that environment. If there is any issue, the deployment team is the one who acts first SPOC. So just make sure, to keep aligning the same sort of organisation process. 

I hope this article gave a few ideas about CI/CD pipeline necessary for our project. If you have any sort of question, please raise it, will pop-in...