Page Comparison

...

• 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:```

    Code Block
    #!/bin/

    bash
    #

    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, less the fewer workflows the better.

  • As such make workflow names generalized for your use case. `cicd` cicd is a perfectly fine good name when compared to `clean-ephemeral-environment`.  You will know what to expect or at least the desired outcome when opening the workflow details in `cicd` 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:

  • Needs more investigationAzure Resources (WIP)

• Databases:

  • Must be uniquely named within our organization

  • Names should follow this format:

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

    • redis, pgsql, are the preferred dbtype names 

    • example: `dstdst-development-redis`redis

• Services:

  • services name should be indicative of both the process and it’s its role in the process. For example - the bare word `invite` is not specific enough. We can delineate between an api 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.