Summary
- Set and enforce standards as early as possible.
- Standardize the whole pipeline.
- Repository Standards: Repo and Branch Names, Branch Protections, and development workflow - CI/CD Standards: Naming, layout, repeatable jobs - Compute resources: VMs, DBs, Serverless

Intro

We’ll be using an example app called Big Fort Inspector. This is a microservices based app deployed via CI/CD practices into a Cloud environment.

Naming Convention

When setting up your resources you want a consistent, from code to Prod naming that can be tracked. The best i have found is to do something like a Three Character Acronym (TCA) It doesn’t have to be 3 characters but I find that 3 is bare minimum when approcing any significant level of scale \

36x36x36=46,656 combinations (26 letters + 10 numbers) though its far less when it comes to basing the TCA off a reasonably readable App Name.

For example if you have an app called Big Fort Inspector you would use the app ID BFI as part of the name for your repository, your CI/CD pipelines related to the app, your cloud resources that are porvisioned for that app, etc. When adopting a microservices architecture where each componenent of your app is in a different repository you would want to add a conmponent ID to the nameing of all resources so that you can track that component through the entire process.

Lets expnad our BFI app example:
Our BFI app has a few components. It has a Front End(FE), a backend (BE) and a serverless “function” that handels file uploads, AWS calls these Lambdas, (FUNC). If you were to create 3 repositories for these components you would name them bfi-fe, bfi-be, and bfi-func to easily identify the different component repos.

Lets go one step further. Say we wanted to add a second function. This one triggers a converter process that takes uploads of Word formatted documents and makes a PDF copy available to the user. Since we didn’t know this when originally creating the first three repos we now run into an issue. We can’t have to repositories called bfi-func most source control services don’t and won’t like it. So what we should do from the very begining is name the first function repo bfi-func-uploads to signifiy that is a component of the bfi app, it is a function func, and that it handles the uploads process. If we do this from the very begining we don’t have to either, rename the repository, OR remember for all time that the bfi-func repo is the uploader code. Now we can create the new function repository and call it bfi-func-pdf-converter