diff --git a/knowledge base/operations best practices.placeholder b/knowledge base/operations best practices.placeholder index b57d895..2b743ed 100644 --- a/knowledge base/operations best practices.placeholder +++ b/knowledge base/operations best practices.placeholder @@ -3,16 +3,30 @@ - Think of KISS to be an invite to keep thinks simple with respect of your ultimate goal.
Avoid simplicity only for the sake of simplicity. - Apply the KISS approach wherever possible. +- Keep in mind things change constantly: new technologies are given birth often and processes might improve.
+ Review everything after some time. - Mind [the automation paradox]. +- Keep things **de**coupled where possible. + 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 early, backup often. +- Keep changes shorts and sweet. +- [Branch early, branch often]. +- [Trunk-based development][trunk-based development: a comprehensive guide] and other branching strategies all work but [have different pros and cons][git branching strategies vs. trunk-based development]. +- Refactoring _can_ be an option.
+ But do **not** use it mindlessly. - Remember that _DevOps_, _GitOps_ and all other corporate bullshit terms are just sets of practices, suggestions, or approaches.
They are **not** to be taken literally, and **need** to be adapted to the workplace, not the other way around. - Amazon's tenets are double-edge swords and, taken literally, only work for Amazon. - Watch out for complex things that should be simple (i.e. the [SAFe] delusion). -- Pipelines' tasks should be tasks one can execute from one's own computer. -- Pipelines are meant to be used as last mile steps for specific goals. - Keep pipelines' tasks as simple, consistent and reproducible as possible.
Avoid like the plague to put programs or scripts in pipelines. -- There cannot be a single pipeline for everything, the same way as _one-size-fits-all_ is a big, fat lie. +- 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. +- Keep _integration_, _delivery_ and _deployment_ separated. + They are different concepts, and as such require different tasks. ## Sources @@ -22,13 +36,19 @@ - [Platform teams need a delightfully different approach, not one that sucks less] - [We have used too many levels of abstractions and now the future looks bleak] - [Why the fuck are we templating YAML?] +- [Trunk-based development: a comprehensive guide] +- [Git Branching Strategies vs. Trunk-Based Development] +- [Branch early, branch often] [safe]: safe.placeholder [the automation paradox]: the%20automation%20paradox.placeholder [a case against "platform teams"]: https://kislayverma.com/organizations/a-case-against-platform-teams/ +[branch early, branch often]: https://medium.com/@huydotnet/branch-early-branch-often-daadaad9468e [culture eats your structure for lunch]: https://thoughtmanagement.org/2013/07/10/culture-eats-your-structure-for-lunch/ [devops is bullshit]: https://blog.massdriver.cloud/posts/devops-is-bullshit/ +[git branching strategies vs. trunk-based development]: https://launchdarkly.com/blog/git-branching-strategies-vs-trunk-based-development/ [platform teams need a delightfully different approach, not one that sucks less]: https://www.chkk.io/blog/platform-teams-different-approach +[trunk-based development: a comprehensive guide]: https://launchdarkly.com/blog/introduction-to-trunk-based-development/ [we have used too many levels of abstractions and now the future looks bleak]: https://unixsheikh.com/articles/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html [why the fuck are we templating yaml?]: https://leebriggs.co.uk/blog/2019/02/07/why-are-we-templating-yaml