Public Website

Deploy to Production via workflow

The Attestant website uses GitHub workflows to control the build and deployment of the website to AWS. To deploy the website do the following:

  1. Create a GitHub issue to cover the work using the templates.

  2. Work locally against a new branch until the website is ready for deployment to the staging environment.

  3. Create a Pull Request against the issue to enable the staging environment to be utilised by the standard workflows.

  4. Correct any build issues (linting etc) and note that if Lint Commit fails the build, you will need to amend the git commit messages as follows (see the GitHub documentation for more details) :

    git rebase -i HEAD~4 # Amend the 4 most recent messages

Within the interactive session either delete the pick line with the offending message (assuming another commit exists containing the changes) or replace the word pick with reword and make the change. As an example:

pick f7f3f6d Change my name  
reword f7f3f6d fix: change my name for #123

When rewording you will need to save and exit the editor (e.g. ESC:wq in vim). In each resulting commit file, type the new commit message, save the file, and close it.

Finally, force push the changes to the upstream repository:

git push --force origin EXAMPLE-BRANCH

  1. Once the build is complete it will deploy to the staging environment for examination by non-technical reviewers. The appropriate link will be provided in the PR comment section.

  2. After successful review and approval, the issue PR can be merged into the master branch.

  3. Once merged the "Pull Request Closed" workflow will automatically remove the changes from the staging site.

  4. Multiple issue PRs can be associated with a release so a build artefact will not be created until a "chore" release PR has been approved and merged. This "chore" release is created from the "Master Push" workflow by selecting a new version number from the drop down menu. Typically this marks the end of the current batch of PRs but isn't strictly enforced. If a "chore" release PR is not created automatically, you should verify that the commit messages adhere to the Conventional Commit standards (see earlier steps).

  5. Once the "chore" release PR is merged the "Master Push" workflow will automatically generate the final build artefact for deployment. This may take some time and deployment cannot proceed until it is completed (reviewers will receive an email indicating the location of the release).

  6. Once the release is complete, the "Production Deployment" workflow can be initiated, entering the required version when prompted. A temporary "deploy" issue will be generated automatically.

  7. Part of the process is the manual approval of the deployment of the release via email (or in the linked GitHub comment thread). Accepted words to enable deployment are detailed in the email, but examples include Approve, Approved, LGTM or Yes. This is handled by the "deploy" issue.

  8. Once approved, the "Production Deployment" workflow will continue to remove the existing website and replace it with the new version.

  9. Reviewers should verify that the replacement website has the correct version as follows:

    • Navigate to https://www.attestant.io
    • Open a developer window (CMD+SHIFT+I) and select Console tab
    • Verify the correct version is listed

  10. A collection of verification tests such as exploring the new content, AOR behaviour and so forth should be performed.

  11. Finally, a message should be sent to [Internal] Frontend Engineering to alert the business that the website has been updated.

Hi all. This release covers [quick summary].

As always, I've checked over the site for any obvious breakages, but if you spot anything please let me know.