Development, Staging, Production

Note: this is an ideal world that assumes we have people who will be able to QA every release. This also assumes a release model (though it assumes nothing about the schedule) rather than continuous deployment.

Also note: Broken code should never hit development, staging, or production. These three branches should be under CI and the CI system should shame whoever breaks the build.

Always fork the project

• Fork the project and work in your own repository. Don't work directly on the master repository, even if you have full administration/push rights.

Lifespan of a feature

• Start with an issue: Awesome Feature X
• Create a feature branch: 999-awesome-feature-x. It's good practice to declare the ticket number at the start of the branch name, but the most important thing is that the branch name easily lets others identify which ticket/issue it relates to.
  • If an issue feels like it's going to take longer than a week, consider breaking it into smaller issues. If that's not possible, rebase from upstream development regularly (at least daily).
• Do the work
• Send a pull-request against the development branch.
• Someone else code-reviews and merges your branch.

Development → Staging → Production

• When it's time to deploy to production, merge to staging, development → staging
• Deploy staging to staging environment, give QA some time to do things.
• As bugs are filed, create new issues and pull against development, then merge to staging.
• Once you get signoff from QA, merge staging → production.
  • At this point, development, staging, and production should all point to the same commit.
• Create a new annotated tag (using date as version?) and deploy.
  • github will automatically create a tarball out of tags, so that can be used for deploys.

Updating the development, staging and production servers

• You can check the current revision of a deploy by going to media/revision_info.txt on the server (e.g., https://thimble.webmaker.org/media/revision_info.txt
• Updates to the development branch are automatically applied to the development server (http://webpagemaker-dev.allizom.org) through a cron job. Updates can take between 5 and 30 minutes to show up.
• Updates to the staging server must be requested from WebOps. File a bugzilla issue, using the "Server operations: Web operations" category, with a request to have the staging branch for github.com/mozilla/webpagemaker pushed to the staging server (http://webpagemaker.allizom.org).
• Updates to the production server must also be requested from WebOps. File a bugzilla issue, using the "Server operations: Web operations" category, with a request to have the production branch for github.com/mozilla/webpagemaker pushed to the production server (http://thimble.webmaker.org).
• When filing a bug to update the server, make sure to fill out the "Additional Comments" section with information about the push. A short changelog would be a good thing.

Hotfixes

• When there's a problem on production, determine if it's serious enough that it needs to be fixed immediately. If it is, create an issue for it, i.e. "hotfix: the site doesn't work in IE"
• Create a hotfix branch, hotfix-999-broken-in-ie. Write a new test case to prove the bug exists and prevent regressions if possible.
• Submit pull request against production. Another developer should both code review & make sure the bug is actually fixed.
• Once accepted, file a bug to get Ops to deploy the production branch to the staging server.
• Make sure, again, that the bug is fixed.
• When completely sure everything is fixed, file a bug to get Ops to deploy production to production.
• Merge production → development and create a new annotated tag.

Rolling back

• Since we've been tagging all of the releases that hit production, it should be as easy as telling Ops to deploy a specific tag to production.