Introduction to CICD - mihirvijdeshpande/devops GitHub Wiki

Some history...

In early days of Software development there was workflow approach like 'Waterfall model' which were dependent on requirement gathering in the planning stage itself. There were very less capabilities to handle new change requests or feature requests if not no possibility. This was okay for its time, however, in current era millions of users affected by slightest issue, lack of features or bug fixes. This intensifies and makes the Overhead of delay ,to make changes only after the initially agreed development is complete, to loose business on greater scales. This lead to rise of Agile and consequently gave birth to DevOps i.e. Agile Development and Agile Operations.

DevOps in brief works on principles of Continuous Development, Continuous Integration along with Continuous Deployment. Which is commonly Known as CICD Pipeline

Building Blocks of CICD

Continuous Integration

Automatically building and unit testing of entire application code Frequently; ideally on source code check-in.

The goal of continuous integration is to keep the software in a working state all the time ~ Jez Humble and Dave Farley, Contiuous Delivery

  • Best Practices :
  1. All builds should pass the coffee test. Build should take less time than it takes to get a cup of coffee(≈ 5 mins). The longer it takes the more tasks are queued to wait.
  2. Commit small bits : Small changes are much easier to reason about and also to isolate problems quickly.
  3. Don't leave the build broken : When the build is left broken that leaves the delivery broken.
  4. Use trunk based development flow : No long running branches, One trunk to merge back to. Always integrated across all developers. All developers work off trunk and commit back to trunk multiple times a day. Instead of keeping multiple branches, devs brach code and use feature flags and the merge back which proves easier to keep track of. The state of DevOps reports specifically identifies this practice as a hallmark of high performing teams.
  5. Don't allow flaky tests, fix 'em ASAP
  6. The build should return status,a log and an artifact. Status should be green or red; logs should include all test-cases performed and all the results of it., Artifact should be uploaded and tagged with a build number.

Countinuous Deilvery

Deploying every change to production like environmenet and performing automated integration and acceptance testing.

  • Best Practices :
  1. Only build artifacts once for staging, testing and production.
  2. Artifacts should be immutable.
  3. Staging should be ideally an exact copy of production. Easily achievable on cloud.
  4. Stop deploys if a previous step fails. Checks should be set and monitored between various stages of Delivery.
  5. Deployments should be idempotent - Redeploying should end in exact state.
  • Improvement scope :
    • Monitor Cycle time and also the time taken by each stage of delivery all the way to production. Also take into consideration frequency of cycles and teamflow . Then think and implement ideas on how each time can reduce the time while maintaining the same quality of delivery.

Countinuous Deployment

After testing of every change it is deployed to production.

The Role of QA

The Continouos Integration and Continuous Delivery seem too good to be true that too without much of any catch. There is one if not a fundamental shift you have to make when you are moving to Continuous Delivery. The one area that deserves the extra attention is testing.

Types of Testing:

  1. Unit Testing
  • Tests done at the lowest level of the language or framework that it supports. It doesn't need external dependencies and could be run on developers machine.
  1. Code Hygiene
  • Usually the best practices hailed by the community for particular framework or language. Achieved by Code Linting, Formatters and Banned functions.
  1. Integration Testing
  • Similar to unit testing but performed with all the components and dependencies operating in a test environment.
  1. TDD, BDD, ATDD
  • These are Test Driven Development , Behaviour Driven Development and Acceptance Test Driven Development. Even though there are some differences they are all a kind of outside looking in perspective with different motivating factor. In TDD you state your desired outcome as a test and write code to pass the test and repeat. In BDD needs you to work with stakeholders who can describe the buisness functionality to be expected in code which then becomes the test base in a natural language descritors. In ATDD it combines TDD and BDD introducing End user's perspective. Use cases are the basis of automated testing and testing is done continouosly until development is complete.

Dealing with slow tests

  • Use Non blocking tests in pipeline
  • Use time-scheduled testing
  • Use monitoring to accomplish some test goals
  1. Infrastructure Testing

  1. Performanace Testing

  2. Security Testing