ProdESP32 #1: Use Version Control

“The code isn’t ready for version control yet.”

That is a statement I’ve heard before. I’ve also heard “I’ll check it in when it’s a little further along.”

If you are creating a production embedded application git init is technical step 0. Before you have written a single line of code a repository needs to be in place. That way, when you write those first lines of code you immediately have a place to store them. And not just locally. You absolutely must have a cloud backup of your code at all times.

Whether that is Github, Gitlab, Bitbucket, or some other provider doesn’t really matter. Although later on we’ll be talking about CI/CD which will likely tie back in to whatever provider you go with. The Production ESP32 blog will use Github but that doesn’t mean it’s the only option or the right option for you.

Action

If you don’t have your project under version control also sometimes referred to as source control), take 5 minutes to fix it today. If you do but you haven’t pushed your code today, fix that. Don’t stress too much about the best branch strategies or commit wording conventions at this point. Just make sure your code is in version control and pushed to the cloud. Note, the remote should never be more than half a day behind what is on your local machine.

• My code is under version control
• All of my latest work is stored on a branch and pushed to the remote

Production Pointers

• Never, ever, EVER store secrets in the source code. That includes Wi-Fi credentials, certificates, security keys, or other sensitive information. All good CI/CD platforms have a way for you to provide secrets to build and deploy processes without having them in the repository itself.
• Use branches and pull requests. Committing to the main branch as a single founder for the first little while won’t ruin your business but it also creates a bad habit. PRs (or MRs if you prefer) allow you to have a nice audit trail and can be easily rolled back if needed.
• Keep the history clean. Don’t overthink this at first but having dozens of commits with the text “more fixes” or “stuff” is not helpful and is, again, a bad habit to get into.
• Small commits. This isn’t always possible but do your best to keep the commits as small as possible. As your team grows your teammates will thank you at code review time. Which segues perfectly to…
• Code reviews. Always do them. You’re a team of one you say? Ok, do them. Review your own code as if somebody else wrote it. I promise you’ll find at least one change to suggest to yourself.

Conclusion

Good version control management ties into the Deterministic, Maintainable, and Scalable pillars of the Pillars of Production. It is especially important as the team grows. It is the source of truth for your technical organization and allows for easy collaboration.

Any other version control pointers you can think of? Please share them in the comments.

Join the community and get the weekly Production ESP32 newsletter. Concise, actionable content right in your inbox.