Repository Driven Infrastructure

Written by: Florian Motlik
5 min read

At Codeship, we’re always striving to keep our development team focused on improving our code and product. Anything beside that is a distraction.

Understanding and dealing with the details on how to deploy infrastructure is unnecessary during daily work. Developers should be able to describe their intent to deploy and then a system should pick that up and follow through on it. For example merging code from a feature branch into a staging or production branch shows the intent to get this deployed into the respective part of the infrastructure. Developers can stay focused on the code and move on to the next task immediately. In our experience the repository is a great way to trigger this workflow as we’re using it constantly and there is no ambiguity, there’s only one last commit on a branch.

Github Flow is a great workflow that makes this easy. For any feature or bugfix we create a new branch, work on it and open a pull request as soon as we want feedback. After merging the branch into controller developers move on to the next task immediately and the controller branch gets deployed.

In our case, Codeship takes over and then tests and deploys, but merging between branchs in the repository is sufficient as a trigger to get anything deployed.

Eventually Consistent Infrastructure

Developers are not actively checking the deployment or status of the deployment in our team. We expect that eventually our system will reflect the latest commit on the branch that is set up for deployment into that infrastructure, or we’ll be notified if something failed. It’s always clear what was deployed last as there can only be one last commit on a branch in git. While we could look at the deployment we never actively do, because we trust the process.

This came up recently with one of our newest hires, David. When he started here at Codeship and released features the first times he actively watched the testing and deployment process. I told him while he of course is free to do that he doesn’t have to and can absolutely go on to the next task. The next day I saw him merging and releasing a feature and he went straight to the next task. He trusted the process and knew expressing his intent to change the infrastructure was enough, everything else was then automated.

This built trust in the process quickly as he didn’t have to understand all the underlying details at first, but could focus on building features and improving the product. Over time he picked up more of the details on how deployment works in our infrastructure, but right away he only needed to know to merge to controller and go on. This process now also means we have a consistent workflow for releasing anything.

A Consistent Workflow for Releasing Anything

We’re not just deploying code, but any part of our infrastructure this way. A few months ago we automated the deployment of our DNS and Ben, who wrote this automation, blogged about this recently. This made our DNS deployment repeatable and easy to understand. We don’t have to describe any of the details of how we run DNS to somebody who just wants to have some CNAMEs set.

We recently hired our VPE Jim and on one of his first days he asked me how he could change DNS entries as part of our move to codeship.com. All I needed to do was point him to the right repository and json file. He opened a feature branch, submitted a pull request, got it reviewed, merged and deployed in no time.

This bought him and us time to learn the details of the system over time without having to push everything onto him or anybody else joining us from day one. This made our onboarding process a lot easier and helped us with our recent influx of new people.

Successful Onboarding by Hiding Complexity

We recently hired 6 new engineers (and are looking for more) to grow the team to 18 people. Onboarding was a challenge, but we solved it very successfully. By having a standard workflow on how to release any part of our infrastructure we could focus the onboarding on details in our code base and how our new employees can be productive quickly.

Whenever an engineer starts a new repository now the same workflow is used. Anybody contributing to any repository can expect it to work the same way. This makes it much easier to jump into different code bases.

Conclusions

With a small team you always want your team as focused as possible and remove any possible distraction. By using our repository and merges between branches in our repository to trigger deployments we were able to unify how any part of our infrastructure gets deployed. This is one of the keys to a productive engineering team here at Codeship. There’s many teams that have done this in the past and thousands of developers doing it the same way on Codeship successfully.

If you have other tips on how to keep people focused on code and your product during development please share them with us in the comments.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.