Skip to content

City Logistics releases

In the application git repo

  1. Update CHANGELOG.md with version number and current date. Push pending commits to master.
  2. Check that build and tms-tests run successfully (#ci in Slack)
  3. If repo is using master branch of tms-common, you should always use tagged release. Running this script will also tag your current repos release
  4. If you DON'T need to update tms-common, you can tag manually
    • git tag v1.2.3.4 && git push origin v1.2.3.4 this will trigger the release build
  5. See #ci in Slack that release build and tests complete successfully.
    • This will push the build to all our servers and is available in few mins to be ran.

Retagging

  • With retagging for example minor change that doesn't require version number to be bumped, you can restart server without updating playbooks. Basically we are reusing the v1.2.3.4 here.
    • git tag v1.2.3.4 -f
    • git push origin v1.2.3.4
    • git push origin v1.2.3.4 --force

In attracs-linux-playbooks

https://github.com/Attracs/attracs-linux-playbooks

Prequisites: You must have our service vault password. If you are to use the helper scripts it should be located in repo root file .vault_password_file

If you need to update service configs, do that before the steps below. There is a convenience script ./scripts/tms-push-configs-stable.sh to push your changes into stable prod servers.

  1. Open your services run file from supervisord/run/tms-<service>.conf.j2
  2. Update the latest version in both command and directory lines
  3. Use the local script to push run config changes to TMS backends with ./scripts/tms-release.sh (you can also use awx.attracs.com which I wont go into detail here)
  4. Open managevisor https://managevisor-nightly.attracs.com/services?filters=dG1z_YnVpbGQ6IGRlcGxveT1zdGFibGU%3D
  5. Click ACTIONS -> Reload supervisor config from the right side of the server header.
  6. Restart each service at a time, one server at a time using the popped up service that informs which service config has changed.
    • For example do all tms-fleet on each server one at a time.
    • Wait and look at the logs after each process restart that server
      • A) boots up correctly
      • B) starts receiving BOTH API and RPC traffic (see printed debug logs). This usually takes between 1-60 seconds.
    • Move to the next server untill all tms-fleet have been restarted.
    • Repeat with the next service if you are doing multiple releases.

While performing release restarts its also good to keep these resources open and monitor them for unexpected metrics or logs: * google cloud log tms stable https://cloudlogging.app.goo.gl/WMDcfjEcrNDJw9Xy8 * grafana/prometheus metrics dashboard https://dash.attracs.com/d/p28JvzJZz/tms?orgId=1&var-deploy_type=stable&var-node=All&refresh=10s