Release Procedure

This is the procedure I (Scott) use. It was passed down from Stephen. YMMV These steps assume that the code you want to deploy is in the staging branch and you've already tested it on staging.

1. Find the last release email and copy it
2. Update all the references to the old release number to the new release number. Be careful with the links, depending how you copy it, they might continue to point to the old release URL.
3. Add features and bugs list to the email. Look at PT to figure out features and bugs. If there are a lot, then select all of them from the last release and use the export to csv. Import the csv into an spreadsheet. Then you can sort and copy the list, usually it requires some tweaking.
4. And information about interactives to the email. Look at which interactives have become public. You can either trust the PT stories or you can download the interactives.json from the old release and staging, and then compare the two with a visual diff program.
5. merge staging into production: git checkout production git merge staging git push origin production
6. Deploy the code to lab: cap lab deploy:clean_and_update During the time of the deploy lab.concord.org will mostly be offline. So it is best to do this during an off peak time. It can take 4 minutes or more. Also sometimes it has failed, usually running deploy:clean_and_update again fixes it. One time it failed 4 or 5 times before it worked.
7. Check if production is working by running through some interactives.
8. Tag the release and push the tag to github: git tag [version] git push --tags. I do this locally on my machine. I think Stephen used to do this on the server itself.
9. ssh [email protected]
10. ./script/create-archived-public-dir.sh [version]
11. ./script/create-symbolic-links-to-archives.rb
12. add output of git shortlog [previous version]...[new version] to the email
13. test the links in the email
14. send the email