Groups of professionals contributing to the same product that are working in isolated silos and not talking to each other is not helping your project one bit.
Break down these silos by having contributors talk to each other and involving them in the bigger picture.
The term full-stack-developer is used to describe a developer whom is fully capable of doing whatever is required. This is the essence of not working in silos.
The ability of a release to be deployed is such an essential part of the delivery that the developer is expected to take full responsibility for this process.
The deployment should be automated because it’s a task that needs to be carried out often and is not necessarily trivial.
You want your deployment as code.
Both successful deployment and functional testing are often considered part of the definition of done.
When we´re building continuous delivery pipelines it’s because we want our developers to have access to, and to execute, the full definition of done.
Use simulators, emulators, containers and VMs to verify your definition of done and ensure stable releases. The closer to production your testing environment, the more confidence you can have in your changes.
Every aspect of your entire development and release process can be traced back to some kind of version controlled code.
This can range from the versions of your dependencies to the configuration of your CI server pipeline.
In this context as code means that it’s persisted in files, it’s syntax can be checked, it has semantic meaning, it’s version controlled and can be executed.
Your software is in production, but how is it doing? You want to have insight into the runtime health of your system.
This includes easy access to runtime statistics such as feature usage, transaction throughput and error situations to ensure the service level. In addition, access to environment health like disk and memory usage, cpu load
Bonus points if your system can alert you before an error occurs.