Skip to content

Instantly share code, notes, and snippets.

Last active Dec 15, 2015
What would you like to do?
A standard timeline outlining/explaining code deployments and migrations.
Code migration and deployment procedures
Outlined below is how code is migrated from branches to trunk with flagged notes outlining where the target
environments actually are.
It also outlines various scenarios, and base term definitions can be found below the diagram.
| Released to testing, local dev |
| as needed as |
| http://{version}.isms.testing |
__ Version branch (e.g. Version 0.1) __ ___ Feature branch ___ ___ Feature branch ___
/ \ / \ / \
/ \ / \ / \
------ mainline trunk --------------------------------------------------------------------------------------------------->
\ / \ \ / \
\___ Hotfix branch ___/ \ \__________ Feature branch ___________/ \
| \ \
+-------------------------------+ \__ Tag release \__ Tag release
| Released to testing, dev as | |
| needed as | +---------------------------------------+
| http://hotfix.isms.testing | | Released to staging |
+-------------------------------+ | at the defined end of a version |
| as http://{version}.isms.staging |
| |
| Once verified, deployed to prod |
| as |
| |
| If it fails verification, a new |
| hotfix branch is instituted and the |
| release is retagged and re-released |
| to staging. |
| |
| If issues are found, but not blocking |
| a new hotfix branch may be instituted |
| and a new version (0.1.1) would be |
| tagged from the completion of the |
| resulting hotfix branch |
Environment Terms
Testing - Volatile, frequently updated environment where data can be expected to be
removed, modified or altered at any interval. Primary consumers are QA and developers.
Staging - Theoretically stable environment used for verifying releases moved to production
as well as conduct acceptance testing of version features. Data is generally in a
consistent state from production (though migrated for the newest version). Updates are
proposed and scheduled at intervals or through communication channels and formal
processes are enacted. Primary consumers are UAT verifiers, QA and developers.
Production - Actively utilized by end users; data cannot be modified without some level of sign-off
code can only be updated when signed off and verified in the staging environment. Data must
be migrated using authorized tools and procedures; backups and rollback plans must be
utilized. Primary consumers are end users.
Development Terms
Version - a set of branches (can be an individual code branch itself)
Trunk - the canonical source of truth for the codebase. Not typically modified directly -- unless as a
hotfix -- through sanctioned branches. Any modifications merged to the trunk must also
be merged to any active branches.
Tag - a static, read-only point-in-time trunk reference. Any and all deployments beyond testing
are based off a tag.
Branch - a localized copy derived from a point-in-time on the trunk. Features or fixes are
developed here before being re-integrated into the mainline trunk. These may be developed
concurrent to other branches and may be re-integrated without waiting for other branches to
do so.
Hotfix - patches applicable to the latest tagged version. Can be in its own branch or applied to the trunk directly
depending on number and severity.
So what I've outlined is a single version branch with a concurrent hotfix branch that is then tagged as a
release. I've also outlined how multiple concurrent feature branches can encompass a single release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment