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 

Comments

Post a Comment

Popular posts from this blog

Colour formatting - Jenkins Console

Image
Jenkins is the main CI tool used in Software industry. This is the backbone tool for all CI and CD implementation, Build - release and deployment methods. With the help of 100s of plugin available around the jenkins, We can achieve so much of automation around build process including build/deployment pipeline, notification, analysis, pre and post build action etc. Jenkins has tremendous power to perform great amount of work around the core build process. Many time we write script in pre and post build action to perform many tasks which is becoming very command and necessary for automation. But the main limitation in running shell script is that it's very difficult to make it more human readable for errors and make it fancy. Today i am going to cover some steps to make the output of shell script colour formatted. Jenkins Configuration Steps First install following jenkins plugin https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin Go to jenkins configurati
Read more

Manage Docker images on local disk

Docker is very powerful containerization technique, and it is becoming famous in short time. People are adapting and containerizing their applications for deployment. Soon container become very heavy and consume too much of disk space, If you do not delete old images and layers you may soon run out of disk space. Here i am trying to cover the ways to regain the disk space consumed by docker images. Moving docker filesystem to bigger mount point. Usually docker keeps all temporary files related to image building and layers at /var/lib/docker This path is local to the system usually at root partition "/" . You can mount a bigger disk space and move the content of /var/lib/docker to the new mount location and make sym link.  This way even docker images occupy space, will not affect  your system as it will be using some other mount location. Remove Old docker images Here are few ways to remove old and unused docker images Removing stopped contai
Read more

How to migrate Parent pom from maven to gradle

Convert Maven parent/super pom to Gradle init file When you think of moving to gradle for some reason from maven, You need to take care of lot of stuff around it, You can find lot of tools and help to convert maven pom.xml to gradle build.gradle But one of the most important task as an engineer or architect would be to convert your super pom (or parent pom) in to gradle init scripts. Gradle init script provides same functionality as Maven super/parent pom. The basic difference is that you can call init script Run time As many as of them This gives us flexibility to change the init script on run time but doubt of not tracking the changes.
Read more