Synerzip facilitates frequent delivery of succesive versions to get early feedback from the market. We have developed a continuous deployment pipeline as shown in the diagram below.

• Commit stage: An automated script would run compilation, unit tests, integration tests, automated code review, code coverage analysis before the developer pushes the code into the repository.
• The repository consists of the source code as well as configuration parameters that control the way the development, test and production environments are configured. No binaries or reports are checked in to the repository.
• Continuous integration server kicks a script that compiles and runs unit/integration tests on the integrated code base.
• This script also packages the binaries in deployable form such as jars/wars etc. and copies them to the artifact storage after duly tagging them with the appropriate version number.
• Automated deployment tools such as puppet/chef allow one click deployment after selecting the right version to be deployed in any of the environments from dev to test to production.
• Use of automated configuration tools ensure that exact version of configuration corresponding to the binaries being deployed are created by checking out configuration files of appropriately matching tag of the version being deployed.
• Developers run the commit stage scripts finally before promoting the build to the test environment.
• Testers use automatically deployed version/build as detailed in step 5. At this stage automated user acceptance tests and performance tests are carried out in addition to few manual tests as required. Bugs if found in this process are assigned to development or the build/version is promoted to production.
• Deployment to production is smooth because the deployment script is well tested in development and testing stages. Release stage testing consists of a few sanity tests which are subset of automated tests conducted in prior stages. Thus minimizing the risk of a build breaking in production.
• In spite of this if the release fails in production, we have a script ready to run and roll back the changes committed to restore the old version. We can reduce the risk further by having a low risk "canary release"