[CEP] Deploy History Report

[esoergel]

Abstract 3rd party environments do not currently have access to commit information in deploy history. This CEP proposes to make this information available on all environments. Additionally, it proposes moving the deploy history report to a standalone page.

Motivation To better keep track of when changes are deployed on third party environments.

Specification

For reference, here's what the deploy report currently looks like: This is at the bottom of the system info page, which is mostly broken and has a lot of other stuff going on.

HQ only stores the diff URL, and then not for third-party repos, this actually looks very easy to address:

• Ensure that diff URLs are passed whenever possible. It looks like last_commit_sha has a sufficient fallback when tags are unavailable, meaning that this clause should be unnecessary.

However, it would be preferable to also correct this to store the commit directly, rather than parsing it from the URL:

• Modify the HqDeploy model
  • The existing fields can remain
  • Add a commit field to store the git commit directly.
  • Add a migration to back-populate this field based on the diff_url field when possible (note that these utils do related stuff already)
• Modify record_deploy_success to also accept this commit field and pass it when instantiating a new HqDeploy.

commcare-cloud will need the following:

• Modify record_successful_deploy to pass the current commit to the mgmt command to be recorded.

And finally, that deploy history table should be moved to a standalone, paginated report. This should fall under the existing "System Health" header.

• It should be modeled after existing hq/admin reports, such as the UserListReport
• If there's a straightforward way to make the report render on initial page load (without clicking "Apply"), that should be done.
• No filters are necessary
• In addition to the existing columns, add one which shows the deploy commit directly.

Impact on users None

Impact on hosting Should make useful information more visible.

Backwards compatibility

Release Timeline

Open questions and issues

[millerdev]

+1

Would it make sense to stop writing a git tag on each deploy? It seems unnecessary if we have a record of deploy commits in the deploy history report. That would reduce the tag clutter in github.

[esoergel]

Would it make sense to stop writing a git tag on each deploy? It seems unnecessary if we have a record of deploy commits in the deploy history report. That would reduce the tag clutter in github.

When I saw that message in my email, I thought for a sec you were quoting me, because I wrote that almost verbatim in the "open questions" section above, but later deleted it. I somewhat agree, especially for the setup_release tags. However, we still lack a cross-environment view of what code has been deployed and where. Tagging excludes 3rd party envs, to be sure, but I think there's value in seeing easily in github whether a commit is on prod or other envs.

Since as a rule, we don't force-push to master, perhaps a better state would be a single current-<env> tag that always points to the currently deployed commit for each environment. Then each environment could hold their diffs and deploy history, but we could still easily see on github where a given commit is live.

As an aside, I'm also mulling over the idea of adding a search field to the deploy history page that accepts a git ref and shows the first deploy to contain that ref.

[millerdev]

perhaps a better state would be a single current-<env> tag that always points to the currently deployed commit for each environment

I like this idea. The only tag we care about 99% of the time is the most recent one (for each env). I've also noticed that the performance of some git tools is negatively affected by the presence of many tags.

As an aside, I'm also mulling over the idea of adding a search field to the deploy history page that accepts a git ref and shows the first deploy to contain that ref.

That sounds useful.

[snopoke]

perhaps a better state would be a single current- tag that always points to the currently deployed commit for each environment

+1