Under ISMS and our audit policy, developers must not push straight to production. We’re a small all-dev shop, and policy still separates deploy/ops from day-to-day coding. Without a dedicated ops hire, production deploys still require approval from someone in a lead/ops-equivalent role. That forced a branching strategy different from the usual one.
Common strategy (excluding hotfix / release)
- Create a feature branch from develop
- Work on feature, then merge into develop and push (dev deploy)
- Business users test on the development server
- After deploy approval, merge develop into master
- Push master (production deploy)
The problem: develop can contain work that has not been approved for production. Merging develop into master would bring those unapproved changes along and violate security audit policy. Normally a deploy operator would control that; we do not have one. Handing full responsibility to every developer also looked too error-prone.
Adjusted strategy
- Create a feature branch from develop
- After development, merge the feature into develop and push
- Business users test on the development server
- After deploy approval, merge the feature into master
- Push master (production deploy)
Merging feature (not develop) into master applies only that developer’s approved work. develop and master never merge directly into each other.
If issues appear in practice we may change strategy again, but without a deploy-ops role this seems the best option for now. If we find a better approach I will update it and post again.
Leave a Reply