Rolling deployment and rollback using GOCD

[Vinodkumar Gopireddy]

Hi,

Is it possible to do rolling deployment and rollback from gocd.

[Jeff]

Yes it is, but it is more of a function of the tools you use to deploy and validate as well as how your process is designed.  GoCD helps through versioned pipelines.

[better ltn]

Jeff,

we have added our git master branch  as material and whenever we make any commit on master, gocd triggers build on our production.  Right now, if something breaks in production we have to reset latest commit on that branch . This is difficult and time consuming. Is there any simple way to achieve this? 

[Ashwanth Kumar]

You can use the >+ button (trigger with options) on the pipeline to rollback to a specific commit. 

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Ashwanth Kumar / ashwanthkumar.in

[Jeff]

Sorry for the delayed response...I do have a few thoughts. :-)

The term "rollback" depends on your definition and/or implementation and what availability your service needs to provide customers.

Rollback could mean any of, or a combination of, the following (there could be other options based on what you build and how you deploy):

1. Create VM snapshots and "rollback" to previous state (revert snapshot) on failed deployment
2. Use Kubernetes features (namespaces, replica sets, rollout/rollback, etc.) to manage docker image versions to do a rolling update and rollback on failure.  (This is actually very slick and something we are starting to explore)
3. Rerun last successful GoCD pipeline instance (only the deployment stages) to redeploy last successful production build
4. Checkout and rebuild from source and retest/redeploy
5. Using infrastructure as code:
1. Dynamically spin up a new virtual environment with the new build (parallel to current deployment) using something like salt-cloud, terraform, etc.
2. Validate new deployment on each node
3. At load balancer, drain, remove and replace each old node in the pool with new nodes
4. If successful, delete old VM's
5. (Rollback) If failure, add old nodes back into and delete failed new nodes from pool

The end goal (from my perspective) is to make the deployment virtually transparent and minimize interruptions to those using the service.  Doing a full rebuild/redeploy from source code is not conducive to rapidly handling a failed deployment.

Focusing on option #3 above, GoCD has the awesome feature of rerunning a pipeline or even a step in a pipeline from the past with all settings, artifacts, scripts, etc just as they were the last time you deployed, assuming you designed your pipeline and process to archive everything as a material that is needed to deploy.  A "rollback" then is simply rerunning the old pipeline using existing artifacts.  There is NO need to go back to the beginning and start from source.

While this isn't always the best or most efficient way, it is (in my not so humble opinion) much better than trying to start from source again that gets a tricky if you have dependencies that are released and/or versioned independently and/or have significant automated QA that must also run (and SHOULD be run if you do a new build).

I'm full of opinions on this :) and am happy to clarify or provide alternate views as needed. 

-Jeff