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. | |
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 http://isms.scholarshipamerica.org | | |
| | | |
| 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