Continuous Delivery and Deployment

 

Continuous Delivery and Continuous deployment

This article talks about continuous Delivery  and Deployment to depict the picture of the reason and what exactly we need to look at before moving to CD.
Many times team may not have achieved the Continuous integration properly, may be due to lack to proper tool, workflow or historical process.

Below is the Presentation on same topic
http://www.slideshare.net/vishal_vsh1/continuous-delivery-41301166 


  • What we need to do before even thinking of CI/CD, what are out prerequisites
    • Source code 
    • Builds System 
    • Deployments 
    • QA Automation
We need to understand  release != deployment


Lets assume with the help of Right source control tool, build system and QA automation team has achieved the continuous integration which means Developers integrate code into a shared repository several times a day and each check-in can be verified by an automated build, allowing teams to detect problems early.

The next step:  From CI to Continuous Delivery deployment

What is exactly Continuous Delivery,  Its attitude to Make Software safe and to go fast
Lets Begin with basic,  How much time it takes to deploy one line change or a small bug fix in to the production?  Exactly our goal should be to achieve this as fast as we can.

Why Need Continuous Delivery?
  • Yes! its Speed which is needed in current fast paced software industry. 
  • Stop waiting around on each other to provide go ahead and open the gate.
  • Quality – It raises the overall quality of your application – No surprises.
  • Capacity and  Clarity – Get every team on one tool – Eliminate manual error

How are we going to do this.....


Key Areas:- 

  • Speed is essential because there is an opportunity and cost associated with not delivering Software
  • Frequent Releases, How Frequent is Frequent Why Developer need to wait after writing code? 
  •  Every build can be potential Release candidate. 

Bottom Line

Remove Manual Work/Steps. 
Move towards complete automation

Delivery Flow

 Here is the Delivery Flow.


Ingredients:-

 Configuration Management 
 continuous integration/ Automated Build 
 Automated Deployment 
 Automated testing

Obviously No single team in a company alone can achieve CD without help of other teams, It needs collaboration and team work to implement it, Lets take a look at what do we need from various teams 
Dev Team 
  • Collaboration - Integration is no longer an event
  • Check In Regularly 
  • Make small frequent releases Because big Change -> Big risk –> Big effort and  Small Change –> Small risk –> Small effort
QA team 
  • Should have complete automation or what ever max is possible. More manual testing leads to more delay.
  •  Keep the Build and Test Process Short 
  • Break the QA automation in small pieces so that they can run simultaneously and do the QA frequently. 
  •  Publish the report
Environment 
  • Should have complete Environment to test everything. 
  •  Flexible and scalable so that multiple env can be spawn any time and can be extended.
  •  Managed as prod or at least similar to prod
This increases Confidence in build’s production readiness reducing release risk.

Main blocker to achieve CD

  • manual work 
  • Lengthy Process 
  •  ticket system 
  •  approval

Now, How do we deal with blockers
Do not add gates, add only checks Adding gates to prevent issues from creeping into prod is not so smart There are many more issues hiding, you just don’t know them
Approval!!!  Why do we need CAB?   
           Dev Sign off 
           QA sign off 
           Ops and Dependency sign off 
           Infra sign off

Dev Sign off -> Use proper Project mgmt tool to track everything goes in to software with adequate workflow. Get everyone together at the beginning so that these will not be surprise at last moment. Keep meeting across the team during entire development.
This way you don't need any approval since you have already taken care of all necessary elements during entire development process.

QA Sign off -> Publish consolidated QA report with each and every build which should  be visible to everyone. You should have proper definition of “Go Ahead” instead of just a random checks, Nobody have to ask QA if they thumbs up for the Go. • Minimum criteria for Q has to be set.

Ops, Dependency and Infra Sign off -> Include them at the beginning of the project. Have capacity and change planning during requirement gathering, This given enough time for ops and infra to get ready for the release. 

Role of SCM/ Release Mgmt 

SCM/ Release Mgmt provide the workflow, tools and necessary filler to enable all team to interact and automated their part.
Below picture shows How SCM and Rlease Management help each team.
Source Code Support  for Dev by defining branching policy, Build Setup Support for Dev team to provide continuous build with predefined configuration and in managed environment which include static code analysis like unit test, code coverage, checkstyle etc..

Enabling QA Automation and reporting via build tools (Like jenkins) to support  QA and Dev to run their automation and aggregate report on central location. which include QA automation/regression, functional code coverage etc..
Infrastructure for QA Support like managing integrating environment, Deployment Automation etc.

Ops, Dev and QA CAB Automation and release planning Support.

Its clearly visible that Continuous Integration and Continuous Deployment is not one man show. Planning, collaboration, teamwork is essential part of the execution.

Tools can be chosen by the org/team which ever is suitable for them but main part is automation and integration of the tool with each other to make flow smooth and free.

You can also find the PPT on this topic here -> http://www.slideshare.net/vishal_vsh1/continuous-delivery-41301166 


Popular posts from this blog

Manage Docker images on local disk

Gradle or Maven - A Dilemma

Setup Docker slaves for Jenkins