Home ▸ Continuous Deployment |
---|
Use this strategy for projects where features get deployed as soon as they're ready.
We follow the GitHub flow workflow as closely as possible. This page showcases common development scenarios and how to deal with them from a branching point of view.
- Branches Overview
- Develop a new feature
- Develop multiple features in parallel
- Create and deploy a release
- Change in plan, pull a feature from a release
- Change request
- Production hot fix
- Develop in a platform repo
Branch | Protected? | Base Branch | Description |
---|---|---|---|
master |
YES | N/A | What is live in production (stable). A pull request is required to merge code into master . |
feature | NO | master |
Cutting-edge features (unstable). These branches are used for any maintenance features / active development. |
hotfix-* |
NO | master |
These are bug fixes against production. |
-
Create a feature branch based off of
master
.$ git checkout master $ git checkout -b MYTEAM-123-new-documentation $ git push --set-upstream MYTEAM-123-new-documentation
-
Develop the code for the new feature and commit as you go.
$ ... make changes $ git add -A . $ git commit -m "Add new documentation files" $ ... make more changes $ git add -A . $ git commit -m "Fix some spelling errors" $ git push
-
Navigate to the project on Github and open a pull request with the following branch settings:
- Base:
master
- Compare:
MYTEAM-123-new-documentation
- Base:
-
When the pull request has been reviewed and , merge and close it and then delete the
MYTEAM-123-new-documentation
branch. This can all be done from the Github pull-request page. -
Deploy
master
to a staging environment to verify (some teams have this automated, some prefer a manual deploy with some conventions, either is fine). -
If everything is good in staging, promote it to production and you're done. If not, roll back production to the previous release and return to Step 1.
There's nothing special about that. Each developer follows the above Develop a new feature process.
During development, make sure to update from master
often so that when you
get ready to complete your feature you don't have to deal with large code
conflicts.
In rare situations you may need to get a fix into production fast! Use this workflow to push a hotfix to production when you can't spare the time to follow the standard 'Develop a feature' workflow.
This is very similar to how we Develop a new feature described above.
-
Make sure your
master
branch is up-to-date$ git checkout master $ git fetch $ git merge origin/master
-
Create a hot fix branch based off of
master
$ git checkout -b hotfix-documentation-broken-links $ git push --set-upstream hotfix-documentation-broken-links
-
Add a test case to validate the bug, fix the bug, and commit When doing a hotfix you should at least pair on the fix with somebody or review it in person with one other engineer before releasing it. We're running without training wheels here and want to do our best not to have to do a stream of hotfixes in production.
... add test, fix bug, verify $ git add -A . $ git commit -m "Fix broken links" $ git push
-
Navigate to the project on Github and open a pull request with the following branch settings:
- Base:
master
- Compare:
hotfix-documentation-broken-links
- Base:
-
When the pull request has been reviewed and , merge and close it and then delete the
hotfix-documentation-broken-links
branch. This can all be done from the Github pull-request page.
A platform repo contains both Progressive Mobile App and Progressive Mobile Web source code.
The development process is the same as outlined above in Develop a new feature.
However, branches have to be prefixed based on the following rules:
app-
, for changes mainly touching Progressive Mobile App code.web-
, for changes mainly touching Progressive Mobile Web code.platform-
, for changes touching both Progressive Mobile App and Web code.