diff --git a/knowledge base/best practices.md b/knowledge base/best practices.md index c27f24f..7ea3e49 100644 --- a/knowledge base/best practices.md +++ b/knowledge base/best practices.md @@ -2,6 +2,7 @@ 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**.
@@ -13,24 +14,27 @@ Based on experience. - Automate when and where you can, yet mind [the automation paradox]. - Keep things **de**coupled where possible, the same way _interfaces_ are used in programming.
This allows for quick and (as much as possible) painless switch between technologies. -- Always think critically. - 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. +- [Keep changes short and sweet][the art of small pull requests].
+ Nobody likes to dive deep into a 1200 lines, 356 files pull request ([PR fatigue][how to tackle pull request fatigue], everybody?). - Make changes easy, avoid making easy changes. - [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. -- _DevOps_, _GitOps_ and other corporate bullshit terms are 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. +- _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][from inboxing to thought showers: how business bullshit took over]. - [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. + 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. @@ -50,6 +54,9 @@ Based on experience. - [Branch early, branch often] - [Amazon's leadership principles] - [Amazon's tenets: supercharging decision-making] +- [How to tackle Pull Request fatigue] +- [The art of small Pull Requests] +- [From inboxing to thought showers: how business bullshit took over]