Devops (WIP)

Yaml not yml

Scripts:

• bash scripts should always have a shebang and be named <script>.sh

• For professionalism and for ease of training for new hires and document your script appropriately.
  Use comments at the top to fill out the following details:

  #!/bin/bash# Author: # Date Created: # Date Last Modified: # Description: # Usage:

Verbose environment names so development instead of dev or production instead of prod

In Terraform use _ not -

Make workflows generalized, the fewer workflows the better.

• As such make workflow names generalized for your use case. cicd is a perfectly good name when compared to `clean-ephemeral-environment`.  You will know what to expect or the desired outcome when opening the workflow details in cicd.

Commands and jobs in CI/CD:

• Descriptive and concise will win for these names

• lean towards reusability and agnostic names instead of making a job `deploy-production` name the job `deploy` with an environment parameter.

logging:

• Always use kebab-case

Azure names:

• Azure Resources (WIP)

Databases:

• Must be uniquely named within our organization

• Names should follow this format:

  • <app-name>-<environment suffix>-<dbtype>

  • redis, pgsql, are the preferred dbtype names 

  • example: dst-development-redis

Services:

• services name should be indicative of both the process and its role in the process. For example - the bare word `invite` is not specific enough. We can delineate between an API service, vs. a schedule, vs a job worker. `invite_worker` is more appropriate in this example

Apps:

• apps have to be unique from the organizational scope. They are not unique to an environment. An app name should follow this pattern:

  • `<application name>-<environment-suffix>

Stacks:

• if a stack is built with shared infrastructure, the name should start with `shared-`. 

• stacks built-in dedicated infrastructure must omit that prefix

Environments

• must be unique to the organization

README.md

• Readme.md should follow best practices for running the application locally, deployment, and any special notes.

• This is a great place to store runbooks - in the event of an outage, what are the signs/symptoms and how do we resolve them in a timely manner?

Reviews

• All IaC changes from outside of DevOps should require a review from the DevOps team and merges should not be circumventing the approvals. This will help avoid cascading failures.