Process for creating a ChurchCRM Release
1. Clean and update the local working copy
-
Change to the ChurchCRM working directory, and destroy any existing vagrant boxes
vagrant destroy -f
-
Checkout the branch to be released, and pull any updates
git checkout master git pull
-
Remove all extra files to ensure a clean build
git reset --hard git clean -xdf
2. Build ChurchCRM
-
Start the vagrant box to build all prerequisites. When build is complete, log into the box on SSH and cd to /vagrant
vagrant up vagrant ssh cd /vagrant
-
Update the Languages files by running:
npm run locale-gen
This will create a new /src/locale/messages.po file. If you have access rights, upload this file to POEditor.com
-
Pull updated translation strings from POEditor.com
First edit BuildConfig.json, and set
POEditor.token
to your personal POEditor API access token. Then, run:npm run locale-download
-
Check in translation file
- Create a new branch from master
- Commit changes to messages.po
- Push the branch to GitHub
- Merge the branch to Master. Note the commit hash - we'll want to compare this against the demosite later.
-
After checking in translation updates, run the NPM build script
npm run package
This will run the following actions: * Generate code signatures * Build zip package
3. Test the build!
This testing should be done to ensure there are no last-minute "showstopper" bugs or a bad build
-
Update the demosite using
npm run demosite
The Demosite push key will be required. Feel free to kick the tires on the demo site at this point one last time. The commit hash on the demo site landing page should match the commit hash from step 4.4
-
Test the zip file in the vagrant QA environment:
-
After creating the release zip archive, copy it to /vagrant-qa
-
Edit /vagrant-qa/VersionToLaunch. Place the filename as the only uncommented line of the file
-
From the /vagrant-qa directory, run
vagrant up
-
A new Vagrant VM wil be started on http://192.168.10.12 with the contents of the release zip. Test major functionality in this QA environment
-
After testing a clean install of the release, test an in-place upgrade of the release.
-
Place a restore of a previous version of ChurchCRM in the /vagrant-qa directory. The file must be named
ChurchCRM-Database.sql
. -
Run
vagrant provision
, and the vagrant VM will be re-loaded with the database pre-staged -
Attempt to log into the vagrant-qa box. The in-place upgrade routines should upgrade the database.
-
-
Test the release package on your own testing server
5. Create a GitHub release/tag
https://github.com/ChurchCRM/CRM/releases
- Ensure you select the correct branch, and that the current commit hash matches the commit you created in step 4.4
- Enter version # as the tag and subject
- Point to the change log
- Upload zip file
- Save the release as pre-release
6. Update release notes and version number
After the tag has been created, update the change log and version number
npm run rev-build
- Also, edit
/src/mysql/upgrade.json
to reflect the current upgrade path. - Commit the changes to a new branch titled
<new-version-number>-starting
- Update git release so it points to the latest version in the change log
7. Update milestones
https://github.com/ChurchCRM/CRM/milestones
- Close version milestone
- Create next version milestone
8. Merge master into develop
- Create a new branch to merge master into develop
- Create a PR to get approval for the merge - sometimes regressions can sneak in here, so be careful!