GIT: GitOps Best Practices at St. Thomas for Workflow and Deployment Automation

At St. Thomas, we follow a GitOps-first approach to development and deployment. Git is the source of truth for both application code and infrastructure. Every change must be version-controlled, peer-reviewed, and deployed via automated pipelines.

While there may be legacy applications that do not adhere to these principles, it is beneficial to the university to start making incremental changes moving existing applications toward compliance and follow these practices from the start of all new projects. Rather than thinking "My application or use is old or unique," think: "How can I strengthen my application with these principles?"

Core Principles

• If it’s not in Git, it doesn’t exist!
  Git is our single source of truth. This means all code, infrastructure, and configuration changes must be tracked in Git. This ensures auditability, consistency, and rollback capability.
• Automation is Confidence. Anything else is just hope.
  Deployments must run through automated pipelines. Manual changes are risky, inconsistent, error-prone, and not considered good CI/CD practice.

Put simply, "If it’s not in the pipeline, it doesn’t go live."

These mantras are more than slogans — they’re how we ensure consistency, traceability, and reliability in everything we build and deploy to our students, faculty, and staff.

Cloud Infrastructure and Pipelines

• Store all pipelines, configurations, and infrastructure in the appropriate SAM Configuration or Terraform repository.
• Always pull the latest changes before making updates.
• Workflow:
  1. Pull the main branch.
  2. Make and Deploy configuration changes via Terraform or SAM.
  3. Commit and push configuration changes back to the repository.

Never leave deployed changes hanging around on your local machine. The repository must always reflect the source of truth for others to review. If there are changes to the cloud infrastructure, they should be reflected by a commit to the repository.

Application Code Workflow

We use a multi-branch repository strategy:

• dev branch
  • Local development and unit tests.
  • May have a localhost or container running to preview changes locally.
  • Push changes to dev for integration with team workflows.
• test branch
  • Deployment branch monitored by the CI/CD pipeline.
  • Merge dev → test to trigger deployment to the test environment.
  • Validate functionality before promotion.
• beta branch
  • Stable branch after successful testing.
  • Considered PROD to implement logging, alarms, dashboards, and performance for a PROD environment.
  • Deployment to beta/staging environment for pre-production validation.
• main branch (prod)
  • Production-ready code only.
  • Deployment to production is triggered automatically from main.

Iterate like this: dev → test → beta → main (prod).

Isolate Work with Side Branches and Pipelines

For busy repositories or applications undergoing a lengthy development project, keep the Git production workflow for the dev, test, beta, and main branches clear!

• Temporary side branches with their own pipelines should be created as needed for features, fixes, and experimentation.
  • Create a descriptive name for the dev branch, such as dev-feature-x, dev-fix-y, dev-joe
  • Create a pipeline branch for automated deployments (test-feature-x, test-fix-y, test-joe)
• Do all your work in the side branches, merging changes from dev into your side branch frequently to keep it up to date with the current application.
• When things look good in your side test branch, merge into the dev branch of the Git production workflow. Or, if it was just an experiment, delete the temporary branches without merging.
• Unused branches should be periodically reviewed and removed.

Unfinished code residing anywhere along the production workflow will negatively impact any hot-fixes or priority development work!

CI/CD Pipeline Standards

When setting up pipelines, follow our CI/CD best practices at St. Thomas:

• Tests are mandatory: Ensure unit, integration, and other appropriate tests are included.
• Use buildspec.yml or GitHub Actions.: Define build and deployment steps declaratively.
• Automate everything.: All file copies, builds, AWS SDK/CDK operations, and deployments must be scripted and repeatable.

Following these practices ensures consistency, reliability, and traceability across our development and deployment workflows.