Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Because the stage_update.sh and prod_update.sh scripts (described in detail on the Management Server 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.

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.

  • No labels