Repository Driven Infrastructure

DevOpsIndustry

Reading Time: 4 minutes

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 master developers move on to the next task immediately and the master branch gets deployed.

Git Flow

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 master 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.

Codeship Build

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.

Sign up for a free Codeship Account

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.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.



We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • Ramón Ramos

    I got here by reddit, coincidentally i signed up for your service yesterday. Advertising aside, i have to say I’m pretty happy with it.

  • Tony

    What tool is it in the second image?

  • My greatest concern still is with getting experienced folk to trust the process, and not fall back on their own methods and procedures, which then makes others on the team do the same thing, while fixing the breaks. Any thoughts?

    • In my experience you have to get buy-in from everyone on the team that this is the new process that makes everyones work easier and better in the long run. They need to hold each other accountable on those standards as well then.

      It needs to be clear for everyone that it is a team decision to go with this particular workflow and going around it might result in problems because something was forgotten and then the whole team has to jump in.

      Its equally important though to have regular develpment team meetings to talk about how happy everyone is with the process and what changes could be done to make it better. Those need to be heard by everyone so you don’t follow a shitty process just for the sake of the process.

  • Paul Welden

    How do your stakeholders review the work being done in this CI workflow?

    • If we need feedback from more people on the team you either add screenshots to the pull request if it is purely visual, if its more UX and you want to see the interaction you can deploy the Feature Branch to QA. For that it works well to set up a deployment so that anytime somebody tags a build with qa/SOMETHING it automatically gets deployed into a QA application. So all of the QA deployment is done through the system as well.

  • ashraf ahmed

    Great article, embracing “everything as code” is great and in my opinion is the best way to keep everything transparent.