OAM best practices

Based on experience.

Always think critically.
The one-size-fits-all approach is a big fat lie.
This proved particularly valid with regards to templates and pipelines.
Apply the KISS approach wherever possible, not to keep all things simple but as an invite to keep things simple with respect of your ultimate goal.
Be aware of simplicity for the sake of simplicity, specially if this makes things complicated on a higher level.
Keep in mind things change constantly: new technologies are given birth often and processes might improve.
Review every decision after some time. Check they are still relevant, or if there is some improvement you can implement.
Focus on what matters, but also set time aside to check up the rest.
Mind the Pareto principle (80-20 rule, roughly 80% of consequences come from 20% of causes).
Automate when and where you can, yet mind the automation paradox.
Keep things decoupled where possible, the same way interfaces are used in programming.
This allows for quick and (as much as possible) painless switch between technologies.
Choose tools based on how helpful they are to achieve your goals.
Do not adapt your work to specific tools.
Backup your data.
Especially when you are about to update something. Murphy's law is lurking.
Branch early, branch often.
Keep changes short and sweet.
Nobody likes to dive deep into a 1200 lines, 356 files pull request (PR fatigue, everybody?).
Make changes easy, avoid making easy changes.
Trunk-based development and other branching strategies all work but have different pros and cons.
Refactoring can be an option.
But do not use it mindlessly.
DevOps, GitOps and other similar terms are sets of practices, suggestions, or approaches.
They are not roles or job titles.
They are not to be taken literally.
They need to be adapted to the workplace, not the other way around.
Be aware of corporate bullshit.
Amazon's leadership principles are double-edge swords and only Amazon can apply them as they are defined.
Watch out for complex things that should be simple (i.e. the SAFe delusion).
Keep integration, delivery and deployment separated.
They are different concepts, and as such should require different tasks.
This also allows for checkpoints, and to fail fast with less to no unwanted consequence.
Keep pipelines' tasks as simple, consistent and reproducible as possible.
Avoid like the plague to put programs or scripts in pipelines: they should be glue, not applications.
Pipelines' tasks should be able to execute from one's own computer.
Pipelines are meant to be used as last mile steps for specific goals.
There cannot be a single pipeline for everything, the same way as one-size-fits-all is a big, fat lie.

6.0 KiB Raw Blame History

OAM best practices

Sources

6.0 KiB

Raw Blame History