sansguidon/bookmarks
1
0
Fork 0
Code Issues 16 Pull Requests 1 Projects 1 Activity

fix spelling/typos

Browse Source
This commit is contained in:
MorganGeek 2020-07-19 11:16:15 +02:00
parent e1125c35f3
commit 127d2f2c19
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
cd/viktor_farcic_on_continuous_delivery.md
View File

@ -13,7 +13,7 @@ By Viktor Farcic [https://www.youtube.com/watch?v=mW_gkQnF4eU](https://www.youtu
* 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. * 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 * 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. * 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 * 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 committing code you didn't test locally should be illegal
* commiting code you didn't test locally should be illegal * committing code you didn't test locally should be illegal
* respect your coworkers * 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 * 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