Deploy from a Git Ref

Deploying the same code to all of your servers helps maintain consistency in your infrastructre.

How do we ensure code consistency across your stack?

When you start a deployment on Cloud 66, here is what happens:

  1. The latest commit of your git/branch is pulled to Cloud 66.
  2. The code is analysed for changes that will require new components to be installed on the servers.
  3. Any changes to infrastructure are applied based on the results of the analysis.
  4. In case of serial deployments, 1 web server is taken offline and the latest code is pushed to it. It is then put back online (behind load balancer). This process is repeated for each web server.
    In case of parallel deployments, the code is pushed to all web servers at the same time.
    Backend servers go through the same process, but without the load balancer modifications.
  5. Final steps of the deployment are taken (cleanup, relevant deploy hooks, notifications, etc).

When a new server is added to a stack, instead of pushing the latest code to the new server, the SHA hash of the git commit running on other servers is used to ensure the new server runs the same code as with the others.

Support for deployment from git refs

Today we are announcing support for deployments from custom git refs.

Using deployment from git refs you can use any valid git ref, like a commit SHA hash, git tag or branch to tell Cloud 66 what code you would like to deploy to your servers. You can use the Toolbelt with this feature. Here is how:

Deploy from a tag:
cx redeploy -s mystack --git-ref v1.22

Deploy from a commit SHA hash:
cx redeploy -s mystack --git-ref a57b7b025b

Deploy from a branch:
cx redeploy -s mystack --git-ref new_staging

Using this feature follows the same principals to ensure code consistency across your stack in the same way as with the normal deployment.

Deployment from git ref takes care of branch switching and cache invalidations automatically. For example if the given commit SHA hash is not part of the currently deployed git branch, then the stack branch will temporarily switch over to the new one. The next normal deployment (without git ref) will reset the branch back to its original value and deploy from HEAD of that branch.

We know many customers wanted to get their hands on this feature and hope this can help them build even more great applications better!

Khash Sajadi

Khash is the founder and CEO of Cloud 66, a full stack container management as a service. Follow him on @khash

London, San Francisco
Subscribe and get updates

Have feedback? Please get in touch @cloud66 on Twitter.

Everything you need to build, manage and maintain containers in production on your own servers and any cloud

Try Cloud 66 — 14 Days Free Trial, No credit card required