TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
🛠 TOOL OF THE DAY
SlimToolkit - Secure your Docker containers without requiring changes to your original container image.
Ideal for use with multiple programming languages on different OS environments.
Make your containers better, smaller, more Secure.
🧠 USE CASE
GitHub Branching Strategy for Multi Account Environments
Efficiently managing deployments across sandbox, development, test, staging, and production accounts requires more than just pushing updates.
An ideal approach should reduce deployment risks, support gated approvals, and ensure that only tested and approved code reaches production, maintaining system integrity across accounts.
This specific GitHub branching strategy proves to be incredibly handy.
Architecture Overview:
Ref: AWS Prespective Guidance
Here’s the simplified breakdown of the flow depicting the movement of code through various environments and approval stages from development to production.
Release Flow:
1. Develop code on the feature/* branch in the Sandbox account.
2. Deploy to Sandbox from feature/* branch for testing.
3. Create merge request for feature/* branch to merge into the main branch.
4. Merge feature/* to main branch.
5. Build, publish artifacts in Develop environment.
6. deploy from main branch to Develop environment.
7. Deploy with gated approval to Test environment.
8. Deploy with gated approval to Stage environment.
9. Deploy with gated approval to Production environment.
Hotfix Flow:
HF1. Develop code on the hotfix/* branch in the Sandbox account.
HF2. Deploy to Sandbox from hotfix/* branch for testing.
HF3. Create merge request for hotfix/* branch to merge into the main branch.
4. Merge hotfix/* to main branch.
5 - 9. Same as release flow. (Develop → Test → Staging → Prod deployments with gated approvals)
Bugfix Flow:
BF1. Develop code on the bugfix/* branch in the Sandbox account.
BF2. Deploy to Sandbox from bugfix/* branch for testing.
BF3. Create merge request for bugfix/* branch to merge into the main branch.
4. Merge bugfix/* to main branch.
5 - 9. Same as release flow. (Develop → Test → Staging → Prod deployments with gated approvals)
Accounts Overview:
Sandbox/Develop Accounts: Feature development and testing are isolated in feature branches. Developers can work on feature branches, manually deploy, and test their changes. Once done, the code is merged into the
mainbranch.Test/Stage Accounts: Here, more controlled environments come into play. Code from the
mainbranch undergoes further testing, and once features are ready for production, they go through deployments with gated approvals to avoid premature release.Production Accounts: The final, stable code on gated approvals gets pushed to production. Continuous integration need to ensure that only stable and verified code reaches production.
Things to Consider:
Automation Pipelines: Ensure that pipelines are automated for each environment, from build to deployment, to avoid manual errors. Use CI/CD triggers to manage this based on branch updates (e.g., only deploy to develop when a branch merges to
main).Branch Naming Conventions: Enforce a strict naming convention for branches (e.g.,
feature/*,hotfix/*,bugfix/*) so everyone knows their purpose.Testing Strategies: Implement a robust testing strategy at every stage. Code in feature branches should be unit tested, while integration and end-to-end testing should happen at the
bugfix/*ormainstages.
Final Thoughts: The success of GitHub branching strategy in multi-account cloud setups depends on defined stages, proper gating, and isolated workstreams, which make the code stable, well-tested, and ready for deployment without causing outages.
You may even like:
Looking to promote your company, product, service, or event to 47,000+ Cloud Native Professionals? Let's work together.
