Version Control
Branches
We use two main branches during our process. master and development.
The master branch is the main 'Production ready' branch. This should contain all the most up to date production code and is protected from any direct manipulation, unless a necessary hotfix is required.
The development branch is the main source of all our other development branches. Development should either be a direct copy of master or will have the next production version ready to be published. We branch off from development when adding any new features or change requests.
If we were adding a new module or feature to a project, we would create a new branch from development, ie. new-hero-module. We would work on this branch locally until it was ready for client testing. We would then merge new-hero-module back into development, which would then be pushed to our projects development or staging environments. Once the client is happy, we would merge development into master before publishing across to the production environment.
Environment roles
Production
The production environment should always be inline with the master branch.
Legacy Staging
Clients can use this to test bigger changes to content if desired. This can be used as a Sandbox, test new scripts and/or plugins (No code updates). This environment should only be used for these purposes.
Staging
Staging environment to be used for maintenance/support, including WordPress and Plugin updates. Developers should copy production to this environment before making any updates. Once everything looks good update those plugins on production and legacy staging (legacy staging gets updated incase clients add new content). Do not simply copy production to legacy staging as to not overwrite client content.
Development
Development environment for testing new features and change requests after golive. Also to be used as the client UAT environment. Once client has approved a change on the development environment, it can be merged to the master branch and pushed to production.