Skip to main content

Post deployment process

info

Use this runbook when you want to work on changes (such as auth hardening) in the Blaster repo, without impacting the main deployment flow. It assumes main is your production branch and develop is your integration branch.

Blaster GitOps series​

  1. Blaster GitOps summary
  2. Blaster repo and branches
  3. Dockerfile & GitLab CI
  4. Clerk authentication & user setup
  5. Google OAuth for Clerk
  6. Blaster prep for automation
  7. Dev app k8s manifests
  8. Dev flux sources & Kustomizations
  9. Dev image automation
  10. Dev SOPS & age
  11. Dev verification & troubleshooting
  12. Dev full runbook
  13. Prod overview
  14. Prod app k8s manifests and deployment
  15. Prod Flux GitOps and image automation
  16. Prod Cloudflare, Origin CA and tunnel routing
  17. Prod full runbook
  18. Post development branches - you are here

1. Branch roles​

  • main
    • Production branch.
    • Only updated via merge requests from develop when you are ready to release.
  • develop
    • Integration branch.
    • All feature branches merge into develop first.
  • feature branches (e.g. security/hardening-auth)
    • Short-lived branches for specific changes.
    • Created from develop and merged back into develop via merge request.

GitLab keeps main as the default branch. That is fine: you will change the target of each feature merge request to develop instead of main.

2. Refresh local branches from origin​

Before creating or updating a feature branch, sync from origin.

# Make sure you are on develop
git checkout develop

# Fetch and rebase onto the latest origin/develop
git fetch origin
git pull --rebase origin develop

If you also need the latest main (for example before a release MR):

git checkout main
git fetch origin
git pull --rebase origin main
warning

Both develop and main branches will change to reflect the new tags after the image registry is automatically updated. Always checkout and fetch both before working on a feature.

3. Create a security hardening branch from develop​

Create your feature branch from develop so it includes the latest integrated work.

git checkout develop
git checkout -b security/hardening-auth
Switched to a new branch 'security/hardening-auth'

4. Push branch and track upstream​

Push the new branch and set the upstream tracking reference.

git push -u origin security/hardening-auth
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
remote: 
remote: To create a merge request for security/hardening-auth, visit:
remote:   https://gitlab.reids.net.au/games/blaster/-/merge_requests/new?merge_request%5Bsource_branch%5D=security%2Fhardening-auth
remote: 
To https://gitlab.reids.net.au/games/blaster.git
 * [new branch]      security/hardening-auth -> security/hardening-auth
branch 'security/hardening-auth' set up to track 'origin/security/hardening-auth'.

5. Keep your feature branch up to date with develop​

As other work lands in develop, periodically rebase your feature branch so it stays current.

# On your feature branch
git checkout security/hardening-auth

# Update local develop
git checkout develop
git fetch origin
git pull --rebase origin develop

# Rebase feature branch onto latest develop
git checkout security/hardening-auth
git rebase origin/develop

If the rebase rewrites commits that are already on the remote, update the remote branch safely:

git push --force-with-lease origin security/hardening-auth

--force-with-lease only updates the remote if it still matches the commit you last fetched, so you do not clobber other people’s work by accident.

6. Confirm clean working tree​

Before you switch branches or pull with rebase, make sure your working tree is clean (or changes are committed/stashed).

git status
On branch security/hardening-auth
Your branch is up to date with 'origin/security/hardening-auth'.

nothing to commit, working tree clean

If you see uncommitted changes, either commit them or stash them before rebasing or switching branches.

7. Create a merge request targeting develop​

warning

GitLab will suggest main as the default target branch. Change this to develop for feature work.

From the GitLab UI:

  1. Click Create merge request for security/hardening-auth.
  2. In the MR form, check the line:
    Source branch: security/hardening-auth → Target branch: main
  3. Click on main and change it to develop from the dropdown.
  4. Confirm it now reads:
    security/hardening-auth → develop
  5. Add a clear title and description, then create the merge request.

If an MR was already created with main as the target:

  1. Open the merge request.
  2. Click Edit.
  3. Change Target branch from main to develop.
  4. Save.

8. Merge into develop​

Once the pipeline for the merge request is green and you are happy with the review:

  1. Ensure the MR still targets develop.
  2. Click Merge.
  3. security/hardening-auth is now integrated into develop.

At this point:

  • Kubernetes dev/prod deployments are still controlled by Flux and the GitOps manifests.
  • main remains unchanged until you deliberately cut a release from develop.

9. Release from develop to main​

When you are ready to promote a set of changes to production:

  1. Make sure develop is green and deployed as expected in your non-prod environment.
  2. Create a merge request with:
    Source branch: develop → Target branch: main
  3. Review, run any final checks, and then merge.

This keeps main as a clean record of what is actually in production, while day-to-day work flows through develop and short-lived feature branches.

The image shows the entire flow from the security/hardening-auth branch commit, through develop merge request, updating the dev image registry automatically, merging the develop branch to production (main) and updating the prod image registry automatically.

10. Disable auto-delete and clean up feature branches​

To avoid surprises like GitLab deleting your source branch while your local checkout still exists, disable automatic source-branch deletion and use a simple manual clean-up flow.

10.1 Disable automatic source branch deletion​

In GitLab for the games/blaster project:

  1. Go to Settings → Merge requests.
  2. In Merge options, untick "Enable "Delete source branch" option by default".
  3. Save the settings.

Your merge requests will still offer a "Delete source branch" checkbox, but it will start unchecked so you consciously decide when to delete a branch.

GitLab merge requests settings screen:

10.2 Clean up a feature branch after merge​

After the merge request from your feature branch (for example security/hardening-auth) into develop has been merged:

  1. Make sure develop is up to date locally:

    git checkout develop
    git fetch origin
    git pull --rebase origin develop

  2. Delete the remote feature branch from GitLab:

    git push origin --delete security/hardening-auth

  3. Prune stale tracking references:

    git fetch origin --prune

  4. (Optional but recommended) Verify the feature branch has no unique commits compared to develop:

    git log --oneline --graph --decorate develop..security/hardening-auth
    git diff --stat develop..security/hardening-auth

    If both commands show no output, security/hardening-auth is just a label on the same commit as develop and is safe to delete.

  5. Delete your local feature branch (safe delete, only allowed if it is fully merged):

    git checkout develop
    git branch -d security/hardening-auth

    If Git complains that it is not fully merged, inspect with git log before considering git branch -D.

  6. Create your next feature branch from the updated develop:

    git checkout develop
    git checkout -b security/next-hardening-thing
    git push -u origin security/next-hardening-thing

This keeps your branch list tidy, avoids stale tracking refs, and prevents surprises from GitLab auto-cleaning branches you still have checked out locally.

11. Verification checklist​

  • Local integration branch is develop and up to date with origin/develop.
  • Feature branch (for example security/hardening-auth) was created from develop.
  • Feature branch tracks origin/security/hardening-auth and is regularly rebased onto origin/develop.
  • No uncommitted changes before rebasing or switching branches.
  • Merge request exists in GitLab with target branch = develop, not main.
  • main is only updated via merge requests from develop when you are ready to release.
  • After merge, feature branches are cleaned up using the manual flow (remote delete, prune, optional verify, local delete, new branch from develop).