Do you use version control?

You’ve probably heard it before, “You should use version control”. This one is a critical. In many cases other recommendations can depend on the size of your team, your organization, its goals, or its values.

Not this. This is a bedrock foundational recommendation. If you want to achieve any sort of reasonable, helpful automation, you must use version control. Why is this? Because you have to be able to recreate previous states if needed. You need to be able to rollback. Your team needs to be able to look back, to see what’s changed. To see how they got to the state today.

If you took your car to a mechanic, he’d ask about what happened before your car got there. How do you drive? What did you experience? What changed? Imagine going and just saying each time “I have no idea, I spaced out every time I drove, and never listened to the noise of the engine.” That’s what it’s like without version control. You can’t answer basic questions.

This isn’t just for when things go wrong though. Your team can be use this information when developing features. They’d be able to check if the feature or a similar one existed before, but was perhaps removed, for example.

It’s a good base for new team members to review as well. It can help them understand how features tend to get developed. That is, fast or slow, many at once, or just one at a time. They can also get a feel for the code review process (or start code review in the first place) and team style this way. Understanding what gets asked about or ultimately revised can help them integrate into the team faster.

Version control also lets you test different versions of your app. Your team can figure out how various features or specific implementations stand up to benchmarks or to your test suite.

Even if you don’t feel that your team is large enough now to warrant this, starting the process from the get go will make it easier to expand the team or get help later and is much safer than allowing potential features to languish on individual developer machines.

Finally, it’s important to actually use version control, not just have it available somewhere. If your team doesn’t use it, it allows the possibility of code and knowledge getting lost and won’t help you.

Complementary Process Diagnostic

With 30 minutes spent looking over your existing pipeline or process, we can diagnose the root cause(s) of slow releases or bugs. After 30 minutes on the phone or Skype with me, you will:

  1. Understand why your existing process may be allowing bugs to reach production and slow you down
  2. Learn ways you can increase the speed that features reach customers
  3. Have a list of ideas for improving your release process

We’ll have to move fast, of course, to get through all this in 30 minutes but don’t worry, I’ll keep us on track. To receive your meeting agenda and scheduling instructions, enter your email address below and click the button.