tips about continous delivery
This commit is contained in:
parent
8a2e5c5672
commit
ab98b1573c
@ -24,6 +24,25 @@
|
|||||||
* Determine the **Historical context** in which the candidate solution was designed or developed.
|
* Determine the **Historical context** in which the candidate solution was designed or developed.
|
||||||
* Weigh **Advantages** against disadvantages. Determine what was de-prioritized to achieve what was prioritized.
|
* Weigh **Advantages** against disadvantages. Determine what was de-prioritized to achieve what was prioritized.
|
||||||
* **Think!** Soberly and humbly ponder how well this solution fits your problem. What fact would need to be different for you to change your mind? For instance, how much smaller would the data need to be before you’d elect not to use Hadoop?
|
* **Think!** Soberly and humbly ponder how well this solution fits your problem. What fact would need to be different for you to change your mind? For instance, how much smaller would the data need to be before you’d elect not to use Hadoop?
|
||||||
|
* [Viktor Farcic](https://www.youtube.com/watch?v=mW_gkQnF4eU) - Jenkins World 2017: The Ten Commandments Of Continuous Delivery
|
||||||
|
* every green commit is deployable
|
||||||
|
* break silos : no departments, no silos. especially no CI/CD department
|
||||||
|
* refactor 2-3 hours every day (to make your application deployable, testable, ...
|
||||||
|
* educate others (the point is not for you to make the work / build pipelines for others) but others need to learn and do it
|
||||||
|
* be small : split monoliths (otherwise they take a long time to test / refactor / build / need big teams etc)
|
||||||
|
* practice TDD. no tests, no commits
|
||||||
|
* define your CD pipeline as code (no more clicking around)
|
||||||
|
* have a fast pipeline (fast feedback is important, in minutes or at best one coffee, no longer !)
|
||||||
|
* priority highest on fixing failed pipelines : never start ignoring failures. there is nothing more important in the world but fixing a failed build. If you don't fix it now it will cost much more.
|
||||||
|
* fix it first, drive later
|
||||||
|
* don't use sonar rules : either your build is ok or isn't, you cannot play with % to decide if your build is ok.
|
||||||
|
* you should your CD pipeline locally : you should not wait for jenkins to do everything. test first locally, then commit and have jenkins do the final verification but commiting code you didn't test locally should be illegal
|
||||||
|
* commiting code you didn't test locally should be illegal
|
||||||
|
* respect your coworkers
|
||||||
|
* continuous integration is about committing only to master branch : working on different branches means you don't trust your process. Ff you trust your process you know that the pipeline will detect problems. working on different branches only delays the detection of problems (verification, integration with everybody's else code). If you really like branches, make short lived feature branches (max 1 day) then merge them back to master and deploy to production
|
||||||
|
* do pull requests
|
||||||
|
* prioritize
|
||||||
|
* finish what you're doing, focus on a small number of tasks in parallel.
|
||||||
|
|
||||||
# from my Bullet Journal
|
# from my Bullet Journal
|
||||||
## Values
|
## Values
|
||||||
|
Loading…
Reference in New Issue
Block a user