Tuesday, May 3, 2016

Continuous Deliver - Introduction

What is CD?


 Every commit made to the workspace should be a release candidate for production and it should be deployable to production using one push button. Release is still a manual process and require an explicit push of a button

Why CD?

  1. Eric S. Raymond: Release early. Release often. And listen to your customers.
  2. Steve jobs: You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.

Problem: Many organizations, release cycle are measured in week or months and release process is certainly not repeatable or reliable because it is manual and often requires a team of people to deploy the software into testing/staging /production. 

 Why release cycle is risky and long?
Most release process included lots of thing as mentioned below, where any once of step may go wrong.

  1. Individually crated environment by IS team
  2. Software installation that the application relies on
  3. Configuration is copied/created thought different process
  4. Reference/Master data are created/copied
  5. Manual patch executed on production need to be  recorded.


 Solution: Continuous delivery practices will enable you to make your release fast, repeatable and reliable, visible though automated process with well-understood, quantifiable risks,  goal is to deliver useful, working software to user as quick as possible.


  Benefits :

  1. Anyone from any team would be able to deploy the production(without special knowledge)
  2. Production  is always production ready throughout its entire lifecycle  
  3. Developers aren't done with a feature  is delivered to QA or when the feature is "QA passed". They are done when it is working in production(production like environment)

Step toward Continuous delivery

Prerequisites

  1. Version control
  2. Builds System
  3. Deployments
  4. QA Automation


 Key component of Continuous Delivery

  1. Configuration Management(CM)
  2. Continuous Integration(CI)/Automated build
  3. Continuous Deployment/Automated deployment
  4. Continuous Testing/Automated Testing

Configuration Management

Configuration management (CM) is the detailed recording and updating of information that describes  application and dependent software, Typically includes 
  1. Versions 
  2. Updates that have been applied to installed software packages 
  3. Locations and network addresses of hardware devices.

Type of CM dependency 
  1. Internal dependency management (Library)
  2. External dependency management(Software/Hardware/OS )
  3. Environmental dependency management(QA/Staging/Production)
Type of configuration
  1. Build time
  2. Packaging time
  3. Deployment time
  4. Startup time
Note: Do not pass the configuration at build time or packaging time, it should be setup at deployment time or statup time thought Environment variable.

Tool need to manage the version control
  1. Version control (git) : Keep everything in version control including internal/external/environmental dependency
  2. Dependency management tool (Gradle/maven): Use this to manage internal application dependency 
  3. Docker/ vagrant /virtualization/Puppet/Chef:  Use this for external dependency management
  4. RDBMS, LDAP, file system, webservice: use any of this to store environmental configuration which should pick the configuration based on environment name.

Continuous Integration

(CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Build Tool: Ant, maven, Gradle, make 
CI Tool: Jenkins, Cruise control, Go, TeamCity, Bemboo

Continuous Integration should include: Unit Test, Component Test, and Acceptance Test

CI mainly focuses on development teams. The output of the CI system normally forms the input to the manual testing process and hence to the rest of the release process. Much of the waste in releasing comes from the progress of testing and operations

CI is not enough as 
  1. Build and ops team is waiting for document for deployment or fix
  2. Tester are awaiting for good build
  3. Dev team receive the bug report a week after the team has moved to new feature.
  4. Discovering toward the end of deployment that something is not compatible.

Continuous Deployment

Continuous Deployment pipeline is an automated process for releasing product from version control to production by any user in the organization

Reference:



Continuous Testing

Write the automated tests at multiple levels (Unit, component. Acceptance and regression) and run them as a part of deployment pipeline, ensure it has great coverage, CI and CD is only possible if the test case has great coverage.  This brings the quality to projects.

Type of testing
  1. Functional Testing (Automated) (QA test)
  2. Unit testing(Automated) (Dev test)
  3. Showcase Usability Testing/Exploratory Testing(Manual) (QA Test)
  4. Nonfunctional acceptance testing(Manual/Automated) (QA test)

Best Practices

  1. Treat your Build script and  configuration same as your code, they should be tested and refactored so that they are always tidy and understandable
  2. Continuous Delivery is a practice, not a tool. It requires a degree of commitment and discipline from teams.. so You need everyone to check in small incremental changes frequently to mainline and agree that the highest priority is to fix the broken build
  3. Follow test driven development as it drive your application design and documentation
  4. Use human readable test and suite.
  5. Write the acceptance criteria and automate the acceptance criteria.

Implementing continues delivery.

Required Tools
  1. Docker is container technology that allow you to package an application with all its dependencies into a standardized unit for software development, In CD it is used to setup the build configuration management(CM)
  2. Gradle is build automation system created upon the concept of Ant + maven + Groovy based DSL instead of XML
  3. Jenkins is integration tool which provide the continuous integration service for development

Build you configuration 

Build installation dependency using Docker
  1. Declare OS/software dependency using Dockerfile, e.g to test the web application using selenium,  we need three docker file for each environment with installation command
  2. Build the image: Execute the Dockerfile and create the image 
  3. Link images based on dependency and create the build environment, Apps dependes on Database
Note: With Docker in place, the software installation will be repeatable and reliable


Build Project library  dependency
  1. Use gradle dependency management tool to define the internal dependenc
Build Script
  1. Use gradle and created the build script to 
    • Compile the code
    • Created the docker environment
    • Run the test for  those environment
    • Destroy the environment (kill the docker container)
  2. Use gradle to generate the various quality and health report 

CI setup

Setup the Jenkins to execute the gradle task which will create the docker environment to run the product.



Continuous deployment pipeline



Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)