From e5f0a21536a2c6ffaeda70d2801bbe3b29f5fad4 Mon Sep 17 00:00:00 2001 From: Michele Cereda Date: Mon, 11 Dec 2023 12:30:02 +0100 Subject: [PATCH] chore: review best practices --- knowledge base/best practices.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/knowledge base/best practices.md b/knowledge base/best practices.md index 41b77d5..c27f24f 100644 --- a/knowledge base/best practices.md +++ b/knowledge base/best practices.md @@ -8,16 +8,19 @@ Based on experience. 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 **de**coupled where possible, the same way _interfaces_ are used in programming. +- 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 updating something. +- 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. +- Keep changes short and sweet.
+ Nobody likes to dive deep into a 1200 lines, 356 files pull request. - 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.
@@ -26,13 +29,13 @@ Based on experience. They are **not** to be taken literally and **need** to be adapted to the workplace, not the other way around. - [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. - 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. +- 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 @@ -64,6 +67,7 @@ Based on experience. [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/ +[murphy's law]: https://en.wikipedia.org/wiki/Murphy%27s_law [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