# Deploys at Gamechanger

DevFeed: [Deploys at Gamechanger](<https://devfeed.tech/articles/deploys-at-gamechanger-19831.md>)

Original publisher: [Read original article](<https://tech.gc.com/deploys-at-gamechanger/>)

Author: GameChanger

Published: 2020-07-28T22:24:51Z

Content type: article

Language: en

Sources: [GameChanger](<https://devfeed.tech/sources/gamechanger.md>)

Topics: [Deployment](<https://devfeed.tech/topics/deployment.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Amazon EC2](<https://devfeed.tech/topics/amazon-ec2.md>), [ci](<https://devfeed.tech/topics/ci.md>), [Dockerfile](<https://devfeed.tech/topics/dockerfile.md>), [Docker Image](<https://devfeed.tech/topics/docker-image.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>)

Tags: [build](<https://devfeed.tech/tags/build.md>), [ci](<https://devfeed.tech/tags/ci.md>), [container](<https://devfeed.tech/tags/container.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [docker](<https://devfeed.tech/tags/docker.md>), [docker-images](<https://devfeed.tech/tags/docker-images.md>), [images](<https://devfeed.tech/tags/images.md>), [load-balancer](<https://devfeed.tech/tags/load-balancer.md>), [protocol](<https://devfeed.tech/tags/protocol.md>)

## AI overview

This article describes GameChanger's deployment pipeline. Each commit triggers CI to build and tag a Docker image, push it to an internal Docker registry, and deploy it to relevant Amazon EC2 instances. The instances start containers, register with a load balancer, and receive deployment notifications through Serf's Gossip protocol.

## Source excerpt

At GameChanger, being able to deploy our changes quickly and reliably has always been important. Over the past few months on the platform team, we've been working to build a simpler and more reliable deployment pipeline to support our product teams in shipping code with speed and reliability. In this post, I'll go over the system that we have in place now, and some of our recent improvements. How deploys our work High Level Overview At a high level, the core of our deployment process involves shipping a docker image to some EC2 instances, and then starting a container with that image. Our main code repository contains a Dockerfile with the required configuration for our live app. After each new commit to our main code repository, Our CI process will docker build a new image with a new tag, and push it to our internal docker registry. During a deploy, we pull that image on the relevant EC2 instances, and start a container with it. Once we have a running container, we register that EC2 instance with a load balancer, and start serving traffic. While the high level is straight forward, there's a lot of work that goes into making sure our deployments happen safely, and at the right time. Once a new image has been pushed to our registry by our CI process, we need to notify all our currently running instances that there's a new version to deploy. Each commit corresponds to a new docker tag that's created during the build. Once the tag is created, we notify our internal deployment service of the new version. Once our tag is pushed, and our deployment service is aware of it, we tell our deployment service to start a deploy, which will send a message to all of our running EC2 instances. Serf Messages We use Serf to send that message out without needing to directly contact every instance. The message we send contains a role and environment. The role is the name of a docker image we want to deploy a new version of, and environment will be production or staging depending on wher