Working with Teams
Teamwork makes the dreamwokridikd. The more people you work with, the more decisions you have to make about how you work.
What Is a Team?
Real quick, for the purpose of this blog, your team is whichever set of coworkers you’ll be immediately working with. You may call these people your team, squad, department, or any other god-forsaken term your management dreamed up to make work more “fun.”
Process
The previous post talked about Agile, which is known as a software development process or software development lifecycle (SDLC). Which specific process you choose is something you’ll want to discuss and decide as a team. These decisions will probably determine and/or be affected by your DevOps decisions.
I’m not going to tell you which process to choose, because every team is different. The one thing I will say is that if you work in a software company, it may not make sense for the process that platform engineers use to match the process that developers use. Keep reading.
Branching & Deployment Strategies
This one is one huge topic that I’m going to try to distill down to a few paragraphs. When you start using Git for your version control, you quickly run into questions about your approach to creating branches. The main question is from what branches you’ll be deploying your changes. This may seem like a simple answer: we deploy from our main branch. But depending on how you will be structuring your CI/CD plan, you may want to deploy from the branch you created to make changes, known as a feature branch. Furthermore, since you are platform engineer, your strategy may be different from the branching strategy your developers are using.
There’s no right way, and your strategy will be a result of a conversation with your team and the developers you are supporting. The best approach I’ve seen for platform engineering has been from Kostis Kapelonis, and rather than me explain it, you should just read his article Stop Using Branches for Deploying to Different GitOps Environments.
However, I will consolidate some of the background from the article. Kostis refers to a branching strategy that is now considered an anti-pattern (meaning, don’t do it) known as GitFlow. This was a good model and deserves credit for its usefulness when it was introduced. The GitHub flow gained in popularity later. Both of these made sense at various times for developers, but trunk-based development is my preferred approach and is recommended by Kostis specifically for platform engineering.
What I like about trunk-based branching is that it forces you to keep your changes small which is nice because your team can review your changes quickly and small changes usually result in fewer errors.
GitFlow
Trunk-Based
Comments