Deployment Process
Pre-Deployment
Testing
Ensure all work has been deployed and tested on a staging theme before starting this process. The client should have reviewed the work, and signed off on it prior to deployment.
If the work requires any changes to products or collections that will affect the live site, create a test product or collection, do not edit a live product.
Raise a PR
All work must be reviewed by a second developer before being deployed.
Raise a new PR, merging your feature branch into the main branch (master or development). Fill out all relevant sections of the PR template, providing enough information for the reviewer to give them context of the task.
You can remove any sections which are not required, for example if no translations are needed the Locales section can be removed
Ensure you provide links to the testing theme, as well as links to the product or collection if required, so the reviewer can quickly and easily find the work.
PR Review
As a reviewer you should start by reading the PR description to familiarise yourself with the task.
Review the code by reading through the changes in the Files section. You should be looking for any potential bugs in the code, or areas where the code does not match the BAO coding standards.
You should not raise 'opinions' as issues. Developers are free to code in the way they prefer, as long as it adheres to the BAO coding standards. All change requests should be provided in a polite and constructive manner
Open the links provided and test the feature to ensure it performs the required task. For larger tasks this process is more involved, and you may want to ensure customiser changes work as intended etc.
If any changes are requested, these must be reviewed, and actioned upon if necessary.
Once the reviewer is happy with the work they should approve the PR
Merge the PR
PRs should only be merged into the main branch once they have been approved.
Deployment
Back up the live theme
Before deploying anything, a backup of the current live theme should be taken, in case there are any issues with the deployment.
The theme should be dated so the client and other developers know which deployment it relates to.
Ensure backups are created for every store the client uses
Update Metafields and Translations
Before deploying the code changes, perform any required changes for metafields and locales.
Create any new metafields and locales, and populate the content if necessary.
Ensure any test content is removed from existing metafields used during testing.
Ensure metafields and locales are created for every store the client uses
Deploy the code
Use the deployment script in package.json to deploy to all live stores. This should ensure that no locales or customiser settings are overwritten with the deployment.
If there is no deployment script, raise this with the Development Director and a script will be added
Populate content
If any content needs to be populated after the deployment, then it should be done. You may need to check with the PM to find out whether the client will populate the content, or whether it should be done for them.
Post-Deployment
Test the changes
Once the deployment has been completed, you MUST test the work before informing the client.
It is not enough to assume the work is correct because it worked on the staging theme
Test any new customiser features to ensure they work correctly, and have been populated as required.
It is always worth testing the checkout flow to ensure your changes have not affected this - browse for an item, add it to the cart and proceed to the checkout.
Identifying issues
If an issue is discovered in testing, publish the backup theme and notify the PM that an issue has been found. If possible, provide an estimate for the fix so they can update the client.
Publish the backup theme before fixing any bugs, do not leave bugs live on the site.
Updating the client
Once the work is live, and tested, you should notify the PM, and the client.
Ensure you send links directly to the affected page, so the PM/client doesn't need to hunt for the new change.
If the client needs to populate any content, provide them with a short description, with links, of where they need to do this. Make it clear if the feature will not be present until they have populated the content.
Notes
- Avoid Friday deployments where possible. The lack of resource over the weekend can mean that any issues may be live longer than necessary.
- PMs may specifically ask for a different process to be followed for a client. If this is the case, you should do as they ask - for example they may ask you not to contact the client until they have reviewed the work.
- If possible, deployments should be done to an unpublished theme, and tested, before deploying live. Some clients are happy to work in this way, but others prefer not to. Ultimately it is their choice, but we should strive to advise this method, to reduce the chance of any bugs going directly to a live store.