PAGNIs: Probably Are Gonna Need Its

There are projects for which CD is not a good idea - projects where financial or physical harm may come to someone if a mistake goes out - but in my experience the majority of projects don't fit that definition.

Also, the great thing about CD is that mistakes can be fixed really quickly: push another commit.

Not using CD is no guarantee that you will ship less bugs. In fact I'd argue that it makes shipping bugs more likely, because the friction involved in deploying means you'll bunch up multiple changes in a single release - and that's a great way to discover bad interactions between changes too late.

(Even if you don't use CD to production, having CD to a staging environment is a no-brainer in my opinion: giving everyone on the team access to a current demo of the main branch is another big productivity boost.)

> In all these cases expert human judgement is needed, it is not wise to automatically deploy changes by developers

Isn't this code review? This can and should be enforced before it goes to automatic deployment. If not, what other expert human judgement is needed?

Yes, you need to reach a certain quality bar of your automated testing, and you may choose to implement a canary system before full deployment, but I see no reason to avoid automatic deployment once these safeguards are in place.

It's still a conscious decision by the person who put the change in master and the person who reviewed it. You just implement the tests at the same time as the thing it's testing and merge them together.

It works fine as long as developers are used to working that way.

Oh yes, migrations definitely. I didn't think to mention them because they're a default part of Django development but I absolutely wouldn't start a project without them.

Job queues for me fall into the same category as feature flags: once you need them they add a huge amount of value, but many projects can survive for a while (or forever) without them and adding them to an existing project usually isn't too painful.

Yeah, you absolutely shouldn't log POST bodies that contain information which shouldn't be made available to your developer team for debugging purposes.

When I implement this pattern I make sure not to log the incoming authentication token - I decode it first and log the user ID. I don't want logs that include secret tokens that could be used to impersonate an end-user.

There are patterns you can use to help with automated redaction: one that I particularly like is using a prefix on fields that should be redacted before being logged - "private_password": "..." for example.

You can also redact things on a specific deny-list, but it's relatively easy for someone to forget to update that. I like to make the redaction mechanism as obvious as possible.

Bit skewed on this one too.

There are cases where the bug is account specific.

I think the compromise here is on shorter retention policy if they contain sensitive info, or granular log access permissions.

Anyone informed better on approaching these scenarios please?

Sentry (or ones favorite error capture and rollup tool); depending on context, Sentry also has a fantastic "what were you doing when ..." feedback capture mechanism, which one can also use as a generic feedback capture tool in lieu of, err, whatever the competitors are in that space

Also, w.r.t. "API pagination", one also need not necessarily alter the API payloads with those previous-next parts -- RFC 8288 defined "Link:" HTTP headers (used by GitHub for pagination) meaning it's cheap to carry that kind of metadata without having to have the metadata inside the payload https://datatracker.ietf.org/doc/html/rfc8288#section-3.5 and https://docs.github.com/en/rest/guides/traversing-with-pagin...

Related to that API payload modification: another consideration is whether one turns on "Ignore Unknown properties" (ala Postel's Law) to allow extending the payload without fear of blowing up the older versions. That one cuts both ways, however, since one would want `{"resutls": []}` to blow up, so maybe a middle ground of saying that any fields beginning with "x-" or "$" are ignored

A slightly more general rule than the pagination one:

Always return objects from a JSON api. (never an array, never just a boolean, etc.)

You are going to need to add something even if it isn't pagination.