4 Things You Were Afraid to Ask About DevOps

4 Things You Were Afraid to Ask About DevOps

#1 What git flow workflow are you currently using, and why?

Depends on the project, but usually we use three branches: master (our HEAD), staging, and production. We use peer-reviewed pull requests to master coming from feature-branches based off JIRA story IDs and their short descriptions. After PR is positively reviewed, the author merges it to master and checks that a build (which is triggered by a commit) passes and works on a dev server.

About once a week we promote dev release to staging where QA team gets their hand on it, making sure it’s ready for prime time About bi-weekly we promote staging release to production.

Of course, sometimes we need to do hotfixes to production, but we make sure we merge them all the way down to staging and master.

#2 What kind of CI setup would you recommend?

Jenkins is old and bulky and Java. CircleCI is among the better alternatives. It’s fast, modern, supports many integrations and notifications (Slack anyone?), and is easy to configure. It’s SaaS, so you don’t really have to manage it. It’s also free for Open Source projects!

#3 What would you recommend in terms of peer code review process?

Don’t focus too much on reviewing! If you have to, it means that you need to hire better people – seriously. Just do quick reviews on pull requests – one person is enough. If you’re about to make some big architectural changes though, then it might be a good time for a conference call with your team members.

#4 How to make sure all dev’s environments are compatible?

It’s hard to document projects – we all know that! But following 80/20 rule, I always make my devs document (and keep up to date!) three things in project’s core README file: what it is, how to run it locally in a dev environment, and how to deploy it. It helps in onboarding new developers a lot.

As to code portability in general, we use Docker + AWS ElasticBeanstalk. Very flexible, very easy to use and deploy. Even though we might develop code locally without using Docker (because it’s slow for auto-reload on projects with 1000+ files), but we always can check if it’ll work in Docker locally. I don’t see any advantages in using Vagrant, to be honest.


If you hire the right people, they’ll figure it out almost instantly. Or they’ll tell you what is wrong with your processes or systems.

Recommended Posts

Leave a Reply