| 1 | # CI Tools
|
| 2 |
|
| 3 | Allgemeines Tooling, welches im Rahmen unseres Release-Prozesses verwendet wird.
|
| 4 |
|
| 5 | **Wichtig:**
|
| 6 | Diese Tools sind ausschließlich für den firmeninternen Gebrauch gedacht. Es handelt sich hier **nicht** um ein eigenständiges Produkt, das im Kundenumfeld zum Einsatz kommen soll.
|
| 7 |
|
| 8 | ## Was sind die Ziele dieses Projekts?
|
| 9 |
|
| 10 | Belastbare Automatisierung kritischer CI-Workflows.
|
| 11 |
|
| 12 | ## Wie kann ich das Projekt aufsetzen?
|
| 13 |
|
| 14 | ### Voraussetzungen
|
| 15 |
|
| 16 | - Node `>= 16.15.x`
|
| 17 | - npm `>= 8.18.x`
|
| 18 |
|
| 19 | ### Setup/Installation
|
| 20 |
|
| 21 | ```shell
|
| 22 | $ npm install @process-engine/ci_tools
|
| 23 | ```
|
| 24 |
|
| 25 | ## Wie kann ich das Projekt benutzen?
|
| 26 |
|
| 27 | ### Benutzung
|
| 28 |
|
| 29 | ```shell
|
| 30 | $ ci_tools --help
|
| 31 | ```
|
| 32 |
|
| 33 | ### Philosophie
|
| 34 |
|
| 35 | Die `ci_tools` automatisieren Teilschritte unseres Release-Prozesses, welche andernfalls manuell ausgeführt werden müssten.
|
| 36 |
|
| 37 | **Prinzip 1: Es gibt keine Abkürzungen**
|
| 38 |
|
| 39 | Die Automatisierung nimmt keine "Abkürzungen", sondern erledigt eine Aufgabe in der gleichen Art und Weise, wie die manuelle Erledigung durch einen unserer Entwickler ablaufen würde.
|
| 40 |
|
| 41 | Das bedeudet, dass die `ci_tools` bspw. genau so mit Git committen, Releases taggen und GitHub-Releases editieren wie ein Mensch das sinnvollerweise tun würde.
|
| 42 |
|
| 43 | Hierdurch wird zum einen ermöglicht, dass bei einem Totalausfall der CI-Pipeline die entsprechenden Befehle auch an einem anderem Ort, zur Not einem Entwicklerrechner, ausführbar sind.
|
| 44 |
|
| 45 | Zum anderen vermeiden wir, uns bei den kritischsten Vorgängen unseres Release-Konzepts unfreiwillig von CI-spezifischen Plugins und deren Möglichkeiten abhängig zu machen.
|
| 46 |
|
| 47 | **Prinzip 2: So wenig Kommandos wie möglich, so viele wie nötig**
|
| 48 |
|
| 49 | Die Kommandos der CI Tools beschreiben zusammenhängende Vorgänge, die sich über unsere Repositorys gleichen.
|
| 50 |
|
| 51 | Beispiele:
|
| 52 |
|
| 53 | - Version gemäß Release-Prozess-Konzept hochziehen
|
| 54 | - aktuelle Version committen, taggen und pushen (mit Changelog als Body des Commits/Tags, danach einmal das GitHub-Release öffnen und speichern, um den Markdown-Formatter von GitHub zu aktivieren)
|
| 55 |
|
| 56 | Wir stellen mit den CI Tools sicher, dass bei diesen Vorgängen bestimmte Vorbedingungen erfüllt sind.
|
| 57 | In einigen Fällen prüfen wir auch den erreichten Zustand eines Vorgangs (unabhängig vom "exit status" des letzten Shell-Befehls).
|
| 58 |
|
| 59 | **Wichtig:** Es werden keine Shell-Befehle gewrappt/abstrahiert, die genauso gut "flach" im jeweiligen CI-Workflow stehen könnten, insbesondere, wenn es sich um projekt-/programmiersprachen-spezifische Einzeiler handelt.
|
| 60 |
|
| 61 | Wir wollen an dieser Stelle vermeiden, dass wir Dinge abstrahieren, die auch gut ohne Abstraktion funktioneren.
|
| 62 |
|
| 63 | So gibt es bspw. bewusst _kein_ magisches Build- oder Test-Kommando in den CI Tools, welches für verschiedene Programmiersprachen automatisch den _"richtigen"_ Build- oder Test-Befehl ausführt, da die Entwickler innerhalb eines Projekts am Besten wissen, mit welchen Befehlen/Tools/Parametern sie am _passendsten_ bauen/testen.
|
| 64 |
|
| 65 | # Wen kann ich auf das Projekt ansprechen?
|
| 66 |
|
| 67 | - René Föhring
|