[mickeyben]

What do you mean by keep track? Do you want to be aware of deployments?

A Slack notification could do it. Or do you want to correlate deployments with other metrics?

In this case we instrument our deployments into our monitoring stack (influxdb/grafana) and use this as annotations for the rest of our monitoring.

We can also graph the number of releases per project on different aggregates.

[tfjaeckel]

I think Slack notifications are really nice to see what's going on right now but not so great to see the state of dozens of service, i.e. what version is deployed to what environment.

Then there is the issue of linking the Git release/tag with the corresponding changes, say from a ticketing system such as Jira. That can be helpful to communicate changes to other people within the organization and to users.

How do you define dependencies for releasing new versions to service? Likely going to happen at some point when you have non-trivial changes to services.

[mickeyben]

> I think Slack notifications are really nice to see what's going on right now but not so great to see the state of dozens of service

Completely agree, that's why we instrument our releases so we can easily see what's deployed by service and environment.

> Then there is the issue of linking the Git release/tag with the corresponding changes, say from a ticketing system such as Jira. That can be helpful to communicate changes to other people within the organization and to users.

Each commit is related to a ticket, helps generate a changelog. We enforce a lot of things in each of our release. We have an internal release tool heavily inspired by shipit from Shopify. We have the concept of soft/hard checker to make sure it won't break or that you aware of what could break with the current diff.

> How do you define dependencies for releasing new versions to service? Likely going to happen at some point when you have non-trivial changes to services.

As I said we instrument our releases and can easily track how changes affects our performance/bugs.

We also try a lot not to release non-trivial changes in one big release by doing stuff like release part of the changes behind a feature flipper first or route only a part of the traffic to the new code path, ...

Then we don't have dozens of different services deployed and we're still a relatively small team (~20) so I'm pretty sure I don't have the full picture just yet :)

[tfjaeckel]

Thanks for adding more color to your original answer.

I like you enforce the commit/ticket relationship. Is this purely an agreed process or do you use other measures to keep things consistent? E.g. we typically add the ticket ref to each commit but at times that gets omitted.

Also, I think that (internal) release tool is something crucial as the team grows. Will check shipit a bit further.

Would you mind expanding a bit on the things you enforce for each of your releases?

[mickeyben]

Sure my pleasure.

> I like you enforce the commit/ticket relationship. Is this purely an agreed process or do you use other measures to keep things consistent? E.g. we typically add the ticket ref to each commit but at times that gets omitted.

We're not enforcing it but we might in the future if the team grows and this gets out of hands. At the moment we're just reminding people that they should and it works great so far.

> Would you mind expanding a bit on the things you enforce for each of your releases?

It's still early but so far we check:

- it's not friday afternoon, we want to avoid as much as possible to have issues on the weekend

- it's not out of office hour - we're still all on the same time zone

- there's no lock (we can lock the release in case something goes wrong)

- there's no schema migration. If there is we remind you how to safely migrate schema and who to ping if you have a doubt (usually it should have been caught at the PR review)

- there's someone from the ops/core team around (connected on slack)

- that there's no translations missing for our main languages (french/english)

- + we do a few sanity checks like that our master staging is healthy (release means promoting our master staging)

edit: also I forgot but this is the shipit I'm talking about https://github.com/Shopify/shipit-engine

[tfjaeckel]

Thank you!