Ansible development workflow (Obsolete)

Owned by Eddie Rubeiz
Last updated: Aug 23, 2021
1 min read

Because the stage_update.sh and prod_update.sh scripts (described in detail on the https://chemheritage.atlassian.net/wiki/pages/createpage.action?spaceKey=HDC&title=Management%20Server%20%28Obsolete%29&linkCreation=true&fromPageId=976945261 page) are run regularly on a cron job, the Ansible staging and master branches are special. The following facts will be counterintuitive to new developers:

  • The Ansible staging branch is applied to all the staging scihist-digicoll servers automatically.

  • The Ansible master branch is applied to all the production scihist-digicoll servers automatically.

  • A developer cannot commit directly to master.

Typical Ansible development workflow

Practically speaking, this means a typical Ansible development workflow looks like this:

  • Check out a copy of the staging branch of ansible-inventory from bitbucket.

  • Make sure it’s up to date.

  • Make some changes to it.

  • Commit and push those changes to staging on bitbucket.

  • Wait a few minutes until the scripts apply the changes to the staging scihist-digicoll servers.

  • Test the staging servers as needed, sshing into them if necessary.

  • Once you are happy with the changes:

  • Make a new PR in Bitbbucket

    • Source: Staging

    • Destination: Master

    • Do not select the option to close the staging branch when you merge.

  • Merge that PR

  • Wait a few minutes until the scripts apply the changes to the production scihist-digicoll servers.

  • Make sure everything looks good in production.