This post is part of a series looking at the many questions a team should be asking themselves about the microservices they own. It owes a massive debt to Susan Fowler’s Production-Ready Microservices, which, while not a definitive list of questions, is undoubtedly a good start. Gone are there days when a team could get away with deploying a service for the first time and _then_ implementing monitoring and logging.

What is the deployment pipeline for the service?

Something always comes along as the next big thing in many software development areas. Although luckily, in the area of CI/CD pipelines, this is a little less frequent. There are only a few natural options, especially in source control.

Just use git. Your team must be able to use git and the basic git commands. It would be best to avoid long-Iived (more than a couple of days) feature branches because it will be horribly painful when you do eventually come to merge. There have been many advances in the world of source control in the last 20 years since I started my career. These have made it much easier to manage multiple repositories and created a framework for managing changes called gitflow.

I remember from the CVS / Subversion days that merging and dealing with conflicts was often tricky. It needed some concentration, but it has not gotten any simpler these days. It’s just that it’s more straightforward. Just trying to avoid it at all costs is best. Don’t splat your changes over someone else’s; this isn’t the best way to endear yourself to your co-workers. The only thing worse is to splat your changes over your coworkers on release day. A special place in hell is reserved for anyone who would do such a thing.

A note on gitflow

It’s a lot of hassle is gitflow. But, on the other hand, this may be one of those situations where an opinionated framework is a better alternative to arguing amongst yourselves about the best branch strategy to use. No one wants that.

Do you know what CI/CD tooling is used?

The critical thing is that everyone knows the answer so that if there is ever an issue which your service, it is not necessary for the special lead developer to be around to make the change, deploy the change, write the theme tune, sing the theme tune.

Jenkins is not my favourite CI/CD orchestrator pipeline runners thing. However, again, I haven’t used any of the others in anger, so it is difficult to say if they are better.

Where is the infrastructure as code?

Another decision you need to make is where to store infrastructure as code. This depends very much on how big your CodeBase is. Suppose you have relatively small discrete services which can be deployed separately. In that case, storing your infrastructure code, CI/CD config and service code all together in the same place in the repository should be fine. If you are deploying a collection of services together, it makes sense for the IaC to be stored alongside it. It makes sense to keep everything as ‘together’ as possible since this will enable you to keep PR/MR reviews to a minimum.

Answering these questions will prompt your team to make sure you know how your services get deployed and whether you think that is the best way for you.