[Propose Update] - Observability

[junners]

Is your proposed change related to a problem? Please describe.

I'd like to propose that having the necessary observability is also an essential part of CD. Much like having the necessary tests be part of the commit to ensure that the software is in a releasable state, having the necessary observability lets you be confident and aware that the runtime did not break. i.e. while the feature isn't active and when the feature is active. This is also because you'd anticipate that you're never sure that after applying your changes, everything will fit together like a glove.

Describe the solution you'd like

It would be an extension or an expansion of prod-like test environments, having the necessary observability in forms of measures, traces and logs definitely help validate if your change is ok.

Describe alternatives you've considered N/A

---

Small note! I understand CD focuses on defining your software to be in a releasable state, however I'd also argue that it should be bare minimum to also understand what happens to your environment, before, during, and after your deployments.. After all, you wanna optimize for sleep, right?

[ferrix]

Observability is certainly a strongly recommended feature of the software deployed through the pipeline and we would definitely consider a concrete proposal.

However, we have concentrated on minimal and universally true requirements for CD and observability is not applicable to cases where the team does not have direct access to the deployed software or the team is not in control when and where the software is deployed. This applies to IOT, non-networked software, firmware, and applications with strict confidentiality and compliance.

[junners]

Thank you for sharing your thoughts! I've not thought about applications that are air gapped, but I still believe there's some sort of monitoring happening after those software are deployed. They maybe in forms of "Problem Report" that engineers can still go into and troubleshoot the device