CI CD & Branching Policies

CI/CD & Branching Policies

Infrastructure

• Neon DB serverless PostgreSQL for database
• Google Cloud Run for hosting and running the containerized backend application
• Google Cloud Buckets for object storage
• Cloudflare Pages for hosting and serving the frontend application as static content via CDN

Environments

• Production: Deployed from the code from the main branch
• Development: Deployed from the code from the dev branch
• Test: Deployed from the code from the pull requests opened to dev branch

Deployment Triggers

• CI/CD Pipelines for backend are only triggered when there is file change under apps/jobboard-backend or that workflow itself.
• CI/CD Pipelines for frontend are only triggered when there is file change under apps/jobboard-frontend or that workflow itself.

Test Environment & Deployment Flow

• There is a single test environment, meaning only one application can be deployed at a time.
• Since the triggers of frontend and backend are separated, it is possible to deploy to frontend test environment from one pull request and backend test environment from another, as long as they only change code under frontend and backend folder respectively. In other words, if a feature is being developed on two separate branches, one for the frontend and one for the backend changes, they can be deployed back to back to be tested.
• The workflow that deploys code from a pull request to the test environment runs whenever a pull request is opened to dev branch AND at each push to a branch that has an open pull request to dev. So if you have an open pull request to dev, beware before pushing new commits to not override the deployments on test environment and interrupt a team member's test.
• The test environment has it's own separate database, and may need to be periodically reset, especially if a test involves changing the database schema temporarily.

Environment Variables

• Variables that change by environments like API URL, Database URL and Website URL should not be hardcoded at codebase. Instead, they should be pulled from the environment variables.
• To add or change the environment variables of deployed applications, the workflow files should be edited.
• If an environment variable is secret and should not be pushed to Github, it should be managed through either the Secret Manager of Google Cloud, Github Actions or Cloudflare Pages depending on the need.

Branching Policy

• The standard procedure of contribution to preserve clean commit history and consistent deployments is as follows:

1. The development should start by branching from the dev branch.
2. Convention for naming branches is feat/issue#-short-description or ref/..., fix/...
3. After the development is complete, a pull request should be opened to dev branch. It is important to note that the default branch is main, and pull requests are opened to main by default unless you change it. Change the base to dev before clicking the "Create Pull Request".
4. After the code on pull request is deployed to test environment and it is tested by the reviewers, it is ready to be merged to dev.
5. For releases to production, merging commits from dev to main should not be via a pull request, as it causes the branches main and dev to have different commit history despite having identical code, and causes confusion at pull requests. Instead, it should be done locally by git checkout main & git merge dev and pushed directly to the remote main branch.

Deployment URLs

• Frontend Prod
• Frontend Dev
• Frontend Test
• Backend Prod
• Backend Dev
• Backend Test