Skip to main content

Command Palette

Search for a command to run...

CI CD Explained

Designing an build pipeline

Published
•3 min read•View as Markdown
CI CD Explained
U

I am a Software Engineer 2 at a Fintech company and am motivated with devops procedures and interested in learning new cloud technologies.

As a DevOps engineer, it's one of my daily tasks to create the application build pipeline. It includes a series of steps to be taken in order to design an automatic pipeline with continuous integration and delivery.

A. Continous Integration

  1. Source code repository

    Repository is a place to store the entire source code in common platform. From a repo, any developer in the organisation whoever has permissions can read/write to it. Also the services in cloud can access to it and build, test or run the application.

    Examples are Github, Azure Pipelines, AWS Codecommit.

  2. Version control

    When multiple developers are working on a application, a proper version control system helps us track these changes. Branching and merging stratergies ensures avoiding conflicts between changes applied to same peice of code. Overall it aids in maintaining our code.

    Example: Git

  3. Pull request policies

    Pull request is a part of the organization's procedure to get peer approvals before merging changes to main development branch. It is not recommended make changes directly in source code. Create a new branch instead, and modify the files in it. Whenever confident with the changes, raise a PR and get it verified. Later, merge it with the main code.

B. E2E testing

  1. Regression testing

    Next important step is to make sure the functionality is not broken. Inorder to automate the testing, pre written scripts or code are used. Based on organisation's methods there can be unit tests, integration tests ,Load and regression tests. While each of these serves different purposes, regression test simulates a real production env and test the application by cross verifying the output using assertions.

  2. Performance testing

    Whenever new changes are applied, it is important to perform a comparison of the response time and all relevant performance parameters for an application with its baseline values. Ideally, a application baseline can be considered as its response time.

C. Deployment to various rings

  1. Deploying to Dev, QA and Prod rings

    Before an application is deployed to the customer, companies may have several procedures in place. One of then is to use it in a series of ring environments, such as Dev, QA, Preview and Prod. A series of tests, such as load tests, synthetic tests etc., carried out at each stage.

  2. Testing in multiple tenants

    The app response actions may slow down because of the distance between server and consumer. To test this we use tenants from different regions and test there.

D. Continous Delivery

  1. Container orchestration

    As a final step, we deploy the container to a cluster. Kubernetes and other managed orchestration platforms makes sure the services are available at any point. We can also configure a DNS namespace, Service mesh for better netwoking capabilities within the application. Also a load balancer service to route the traffic and scale up/down based on incoming traffic.This makes our application highly scalable and fail proof.

  2. End user delivery

    Finally, customers or end users can connect using the URL(DNS domain name+ service name) after it is deployed.

By following above steps, the application would be thoroughly tested in all aspects and is production ready.

But there is another important category that all devops guys must think of is 'Security'. We should be cautious at every step of the automation process. Few of them includes restricting access to people and services by adopting IAM roles & policies by giving least priviliges. Using Secrets or Key Vault services to store sensitive data like DB credentials, registries .. after encoding them.

Its not just DevOps anymore it is DevSecOps because its better to be safe than be sorry.

More from this blog

DevOps Explain

13 posts