Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement

Hallo,

ich bin was Projektmanagement/Strukturierung angeht vollkommen ahnungslos und möchte nicht im Chaos versinken 😁

Ich suche jetzt also eine Client-Server-Software (internes Netzwerk, kein Web), die den Entwicklungsprozess in irgendwelchen Phasen übersichtlich darstellt.

Konkrete Wünsche wären:

• Rechtevergabe für bestimmte Gruppen und Aktionen
• Einrichtbare Zwangsbedingungen für gewisse Aktionen (Release erst wenn ....)
• Bugtracker: Hinzufügen, erledigt, war doch kein Bug sondern ein Feature 😁 ...
• Suchfunktion für die Bugs: Gefixt ab Version 1.0.1.0 ....
• Idealer Weise eine Versionsverwaltung, so dass man sich das Projekt und/oder die kompilierte Datei direkt vom Server ziehen kann.
• Daher auch: Ablage für Zwischenstände (oder ganze Ordner/Zip Dateien)
• Wunschliste unsortiert und als zu eingeplante Features
• Einstellbare Infobox bei Projektupdates
• Setzen auf "Release" kopiert automatisch die festgelegten Dateien in einen Zielordner

In meiner Fantasie sehe ich einen Eintrag in der Bugliste, behebe den Fehler, ändere die Versionsnummer, klicke im Projektmanager auf "Update" (oder so) und es erscheint ein neuer Eintrag bei dem Programm mit neuer Versionsnummer und Trackercode vom Bug.
Und wenn sich mal jemand fragt, ob der Fehler schon behoben wurde, sucht er sich den Bug raus (nach irgendeinem Suchparameter), sieht, dass der grün ist, klickt drauf und sieht direkt: Ab Version XYZ ist das behoben -> Rechtsklick -> Datei speichern unter -> hat sich die neue Version kopiert.
Und wenn man möchte bekommt man auch eine PopUp Nachricht wenn ein bestimmter Fehler weg ist oder sowas.

Gibt es sowas in der Richtung? 🤔

Als erstes: wenn ich mir die Punkteliste so anschau dann arbeitet ihr etwas wirr; weniger an üblichen Prozessen wie DevOps orientiert.
Da werdet ihr es natürlich schwer haben Tools zu finden, die euren persönlichen, eingeschliffenen Flow matchen.

Die üblichen Verdächtigen jedoch sind:

• Azure DevOps (ehemals Visual Studio Team Services)
• GitHub Enterprise
• GitLab Enterprise
• BitBucket

Aber:

Setzen auf "Release" kopiert automatisch die festgelegten Dateien in einen Zielordner

So funktioniert prinzipiell kein ordentliches Release Management im Sinne von DevOps.
Ein Release Management besteht immer aus Umgebungen; man spricht heute von Ringen oder Channels.
Explore how to progressively expose your Azure DevOps extension releases in production to validate, before impacting all users

"Ein" Release und Bang - das gibt es eigentlich nicht.
Oft:

• Ring 0 - Entwickler
• Ring 1 - Alpha Users
  ....

Beispiele:

• Windows hat Insider Fast, Insider Slow Channels.
• Docker Hat Edge und Stable Channels

In diesem Falle ist aber Azure DevOps das einzige Produkt mit einem entsprechenden, integrierten Release Management.
What is Azure Pipelines release service?

Wunschliste unsortiert und als zu eingeplante Features

Wie arbeitet ihr? Agile? 🤔

Vermutlich wäre es besser, wenn ihr mal eure Entwicklungsprozesse genauer anschaut; wie sie sind und wie sie (mittlerweile) sein sollten (Stichwort DevOps) und wie Continuous Integration und Release Management funktioniert.

Danach denke ich, dass ihr mit VSTS bzw. Azure DevOps eine gute Basis habt.
Azure DevOps ist prinzipiell kostenlos (weitere Features kostenlos via MSDN Lizenz), Cloud-basiert oder mit dem Azure DevOps Server On-Prem nutzbar.

PS: Ja, ich selbst verwende aktiv (und am liebsten) Azure DevOps; nutze aber auch GitLab und GitHub im Rahmen von Kundenprojekten.

Ich bin mir nicht sicher, ob das nicht alles zu komplex ist.

Es geht mir weniger um den Entwicklungsprozess an sich, sonder mehr um die Kommunikation mit Leuten, die daran nicht direkt beteiligt sind. Die sollen möglichst simple informiert werden.

Es kann aber auch sein, dass das bei deinen Vorschlägen mit dabei ist.

Ich werde mir das aufjedenfall ansehen.

Die Frage nach der Agilität ist garnicht so leicht zu beantworten. Ich (und andere auch) arbeite normalerweise eigenverantwortlich an kleineren Modulen/Ergänzungen eines Gesamtprodukts und daher nicht agil. Von daher ist ein "Release" aus meiner Sicht kein Loslassen auf die Menschheit, sondern eine Bereitstellung eines Moduls.

Aber vielleicht trifft dein Vorschlag ja ins Schwarze, ich werde es mir ansehen und ansprechen.

Es geht mir weniger um den Entwicklungsprozess an sich, sonder mehr um die Kommunikation mit Leuten, die daran nicht direkt beteiligt sind. Die sollen möglichst simple informiert werden.

Korrekt, sowas ist Aufgabe einer integrierten Software wie VSTS/AzureDevOps.

Von daher ist ein "Release" aus meiner Sicht kein Loslassen auf die Menschheit, sondern eine Bereitstellung eines Moduls.

Auch das ist ein Release; egal ob es sich um eine interne Version handelt oder eine externe.

Erstmal nochmal danke für die Antwort.

So ganz verstanden habe ich das Lizenzmodel von Devops aber noch nicht.

Ohne Cloud benötigt man eine Team Foundation Server Lizenz + Client Lizenzen für alle, die darin arbeiten sollen, "Projektbeteilgte", also Nutzer, die das System nur als Informationsquelle nutzen brauchen wohl keine Lizenz?

Ohne Cloud und Web-Interface nutzt man dann "Team Explorer Anywhere"?

Ich finde das Lizenssystem vom TFS (zur Vereinfachung) auch ein bisschen unübersichtlich. Aber Grundlegend ist schon richtig was du sagst, Nutzer die das System nur als Informationsquelle brauchen, brauchen keine Liezens. Man kann aber auch ohne CAL zu brauch noch mehr machen. Da solltest du dir aber dann mal genau die Lizenzen anschauen.

Auch ohne Cloud hat der TFS ein Webe Webseite, die im allgemeinen für den zugriff (auf die Informationen) genutzt wird. Es gibt aber auch noch unterschiedliche Tool mit denen man zugreifen kann.

Das Lizenzmodell ist sehr einfach:

Prinzipiell nutzt man weder Azure DevOps (VSTS) noch Azure DevOps Server (TFS) ohne Web UI (das gilt übrigens auch für GitLab, GitHub oder BitBucket).
Team Explorer Everywhere ist meines Wissens gar nicht mehr aktiv in der Weiterentwicklung.

Im Prinzip gibt es bei Azure DevOps (VSTS) drei User Level:

• Stakeholder (generell kostenlos; eingeschränkte Funktionalität)
• Basis - Alle Basisfunktionalitäten (kein Premium), 5 kostenlos
• Visual Studio Enterprise - alle Features inkl. Premium-Features (wie Package Management)

Sprich, wer nur ein Visual Studio Professional hat (inkl. Subscription) gilt als Basisuser.
Wer eine Enterprise Subscription hat, hat alles in Azure DevOps (außer natürlich Drittplugins) kostenlos.

Für TFS gilt folgendes:
(der TFS heisst erst mit der nächsten Version Azure DevOps, hier könnte sich das Licensing weiter vereinfachen).

• Früher hat man einen TFS Server zB drei Jahre lizenziert; heute:
• Mit jeder MSDN Subscription bekommst Du automatisch eine Serverlizenz und eine User CAL. Du kannst also den TFS "kostenlos" nutzen, wenn ihr alle eine MSDN Lizenz habt.
• Mit jedem bezahlten Azure DevOps (VSTS) User bekommst Du automatisch eine User CAL, die Du auch für den TFS nutzen kannst

Nach weiterer Recherche tut sich ein richtiges Wissenlücken-Tal vor mir auf ...

Werde mir in nächster Zeit mal diverse Trail- und Free-Versions auf meinem Privatrechner ansehen und ausprobieren.

Habe Gitlab mal einer VM eingerichtet und die entsprechende Erweiterung zu Visual Studio hinzugefügt und bin u.A. etwas von dem Vokabular erschlagen.

User, Gruppen, Projekte erstellen und synchronisieren, Bugreports erstellen, mit User verknüpfen, schließen klappt alles.

Fragezeichen ergeben sich bei: Organisation der Projekte ,Milestones, Rechte der User, Repos spiegeln (wenn das Sinn macht?), Tests, deployments, environments, CI / CD ....

Ich stelle mir das anhand von ausgedachten Situationen jetzt mittlerweile so vor (mit Gitlab als Beispiel, kann auch gerne anhand von anderen Tools erläutert werden, da ist noch nichts festgelegt):

Beispiel 1:

Ich arbeite an Plugin1 für Anwendung1. Anwendung1 ist schon released.
Jetzt erstelle ich also in Gruppe Anwendung1, Untergruppe Plugins das Projekt Plugin1. In Visualstudio erstelle ich das Projekt und pushe meine Arbeit als "Development" Branche in das Projekt Plugin1.
Irgendwann dann in Master und von Master in Deployment oder sowas.

Gitlab soll bei Aktualisierung des Release-Stands von Plugin1 die Daten zu Anwendung1 packen.

Beispiel 2:

Ich habe eine Programm und möchte davon eine Variation erstellen.
Gitlab soll für bestimmte Gruppen automatisch beim Erstellen eines Projekts ein anderes Projekt spiegeln und Änderungen in der Quelle in den Fork übernehmen.

Ginge das so?

Und eine Frage zum Testen:
Irgendwer(tm) meinte, dass man das Testen der Software insofern damit Verknüpfen kann, dass der Tester bei Fehlern direkt eine Anmerkung in den Code schreiben kann und/oder, dass es für den Bugreport direkt eine Info über die Codezeile gibt.
Wie soll das denn gehen?

Edit: Ich komme wohl nich drumherum mir mal bei MS privat was in der Cloud anzulegen und zu experimentieren.

Jetzt erstelle ich also in Gruppe Anwendung1, Untergruppe Plugins das Projekt Plugin1. In Visualstudio erstelle ich das Projekt und pushe meine Arbeit als "Development" Branche in das Projekt Plugin1.

"Development" Branch hört sich nach einem GitFlow an - ein Ansatz, der eher zu Wasserfall-Projekten passt.
Schau Dir bitte den GitHubFlow an.

Ich habe eine Programm und möchte davon eine Variation erstellen.

Auch das ist wohl eher Wasserfall.
Modern würde man Variationen via Feature Flags umsetzen.

Gitlab soll bei Aktualisierung des Release-Stands von Plugin1 die Daten zu Anwendung1 packen.

Je nachdem was hier "Daten" sind kann das das Prinzip von DevOps verletzen - oder nicht.
Was soll hier passieren?

Ich stelle mir das anhand von ausgedachten Situationen jetzt mittlerweile so vor..

... dass Du erst mal eure aktuellen Prozesse evtl. infrage stellst..? 😉
Es hört sich vieles bei Dir / euch danach an, dass eure Prozesse nicht unbedingt einem modernen, etabliertem Arbeitsumfeld in der Software Entwicklung entspricht, sondern viel "historisch gewachsen" ist.
Das ist prinzipiell "nicht schlimm"; ich treffe auf viele solcher Umgebungen - aber man muss es halt mal gerade ziehen, bevor es dann wirklich explodiert.

Die Ausrede (die ich zumindest öfter höre), dass man es nicht anders machen kann, weil man keine Tools findet, die gewachsene Prozesse abdecken; das ist aus meinen Augen eher ein Eingeständnis 😉

Irgendwer(tm) meinte, dass man das Testen der Software insofern damit Verknüpfen kann, dass der Tester bei Fehlern direkt eine Anmerkung in den Code schreiben kann und/oder, dass es für den Bugreport direkt eine Info über die Codezeile gibt.

Ein Build darf niemals den Code verändern. Der Code ist auch die völlig falsche Stelle für das Tracken von Bugs oder fehlgeschlagenen Tests.

Ein automatisch Bug kann erzeugt werden - und je nach Programmiersprache kann natürlich der dazugehörige Test im Bug direkt verlinkt werden.
Es kann aber natürlich nur der Test selbst verlinkt werden und nicht "jede" Codezeile (zumindest VSTS kann das).

"Development" Branch hört sich nach einem GitFlow an - ein Ansatz, der eher zu Wasserfall-Projekten passt.
Schau Dir bitte den GitHubFlow an.

Mach ich.
Ja meine Arbeit ist definitiv nach dem Wasserfallmodell. Ob das Gesamtpaket aus diversen Modulen dann noch unter Wasserfall fällt, weiß ich nicht. Wohl eher eine Mischung.

Auch das ist wohl eher Wasserfall.
Modern würde man Variationen via Feature Flags umsetzen.

Ja, geht nur nicht überall, bzw. an einigen Stellen würde das grundlegende Änderungen erfordern und das wird geschoben...

Je nachdem was hier "Daten" sind kann das das Prinzip von DevOps verletzen - oder nicht.
Was soll hier passieren?

In dem Beispiel sollte das fertig kompilierte Plugin zum Gesamtpaket der Anwendung kopiert werden.

... dass Du erst mal eure aktuellen Prozesse evtl. infrage stellst..? 😉
Es hört sich vieles bei Dir / euch danach an, dass eure Prozesse nicht unbedingt einem modernen, etabliertem Arbeitsumfeld in der Software Entwicklung entspricht, sondern viel "historisch gewachsen" ist.
Das ist prinzipiell "nicht schlimm"; ich treffe auf viele solcher Umgebungen - aber man muss es halt mal gerade ziehen, bevor es dann wirklich explodiert.

Die Ausrede (die ich zumindest öfter höre), dass man es nicht anders machen kann, weil man keine Tools findet, die gewachsene Prozesse abdecken; das ist aus meinen Augen eher ein Eingeständnis 😉

Da bin ich ja gerade dabei.
Hier entspricht überhaupt nichts dem Modell eines modernen Entwicklungsprozesses. Ich bin hier relativ neu und merke nur einfach, dass für mich das bisherige System extrem anstrengend ist und ich dabei bin den Überblick zu verlieren wer wie wo was wann... 😉
Die Kollegen haben das Problem nicht, sind aber offen für Änderungen.

Ich bin allerdings kein Informatiker oder IT'ler sondern schnöder Physiker. Die ganzen Entwicklungsprozesse sind unbekannten Terrain. Von daher ist es mir eigentlich auch relativ egal wie der Prozess am Ende aussieht, hautpsache es hat Struktur.

Ein Build darf niemals den Code verändern. Der Code ist auch die völlig falsche Stelle für das Tracken von Bugs oder fehlgeschlagenen Tests.

Ein automatisch Bug kann erzeugt werden - und je nach Programmiersprache kann natürlich der dazugehörige Test im Bug direkt verlinkt werden.
Es kann aber natürlich nur der Test selbst verlinkt werden und nicht "jede" Codezeile (zumindest VSTS kann das).

Ich meinte aber eher händische Nutzertests und keine Komponententests. Kann man die ausgeführten Aktionen vielleicht loggen?

In dem Beispiel sollte das fertig kompilierte Plugin zum Gesamtpaket der Anwendung kopiert werden.

Das würde/könnte man über ein Paket-Management zB NuGet lösen.

Ich meinte aber eher händische Nutzertests und keine Komponententests. Kann man die ausgeführten Aktionen vielleicht loggen?

Ja, in VSTS durch das Testplan Feature.
Automated and Manual Testing with Azure Test Plan

So richtig weiter komme ich bei meiner Umstellung leider nicht.

Die reine Verwaltung von Code für ein Projekt in Gitlab mit Branches, Übersicht über die Commits und dem Bugtracker gefällt mir zwar gut und schafft ja auch Übersicht, aber alles weitere erscheint mir doch als Overkill und unnötig kompliziert.

Für Teams, die wirklich gemeinsam an einem Projekt arbeiten mag das ja alles gut sein, für mich scheint die ganze CI/CD Geschichte aber eher Arbeit zu erzeugen, als zu sparen.

Zudem fehlt mir die gewünschte Schnittstelle zu Personen außerhalb der Entwicklung. Issues anlegen per Mail ist zwar schon ganz praktisch, aber es fehlt die Zugänglichkeit zu den eigentlichen Dokumenten und Builds.
Wir haben hier auch oft Sonderlösungen, die vor Ort eingerichtet werden müssen, da soll direkt über das Projekt in der Verwaltungssoftware alles Notwendige ersichtlich sein.

Ich habe mir auch Azure angesehen, das ist schon eine schöne Sache 😉
Allerdings schwierig im Alltag auszuprobieren, es soll nichts in die Cloud.

Vielleicht sollte es mehr Richtung Jira gehen?

aber alles weitere erscheint mir doch als Overkill und unnötig kompliziert.

Dann hast Du den enormen Benefit noch nicht entdeckt 😉

Zudem fehlt mir die gewünschte Schnittstelle zu Personen außerhalb der Entwicklung. Issues anlegen per Mail ist zwar schon ganz praktisch, aber es fehlt die Zugänglichkeit zu den eigentlichen Dokumenten und Builds.

Von was für Dokumente sprechen wir? Ein Quellcodeverwaltungssystem ist kein ordentlicher Platz für Dokumente im Sinne der Kollaboration.
Zudem brauchen Stakeholder nie(!) Zugriff auf Builds!
Worauf brauchen Sie denn beim Build Zugriff, auf Artifacts? Oder was meinst Du mit "Build" ?

Ich habe mir auch Azure angesehen, das ist schon eine schöne Sache 😉

Allerdings schwierig im Alltag auszuprobieren, es soll nichts in die Cloud.

Willkommen im Jahr 2018 😃

Vielleicht sollte es mehr Richtung Jira gehen?

Jira ist nur ein Bug Tracking System - für Build und Co hat Atlassian andere Produkte.

Wir haben hier auch oft Sonderlösungen..

.. und das kann kein Tool abdecken.
Tools wie VSTS, Jira, GitLab und Co orientieren sich an etablierten Prozessen in der Software Entwicklung - nicht an Sonderlösungen bzw. historisch gewachsene Prozesse 😉

Dann hast Du den enormen Benefit noch nicht entdeckt 😉

👅

Mööööglicherweise!

Ich weiß auch nicht, was da genau alles möglich wäre. Gerade im Bezug auf GitLab und die unterschiedlichen Ausstattungstufen.

Kannst Du eventuell ein wenig aus deinem Alltag schreiben, damit ich eine Vorstellung von einem "typischen" devops-orientierten Workflow bekomme? Denn bis auf die deutlich bessere Versionsverwaltung sehe ich jetzt nicht so unbedingt den riesen Vorteil. Es schreiben nicht mehrere Leute an einem Code oder sowas.

Azure Test Plans mal außen vor gelassen, den Vorteil sehe ich 😉.

Von was für Dokumente sprechen wir? Ein Quellcodeverwaltungssystem ist kein ordentlicher Platz für Dokumente im Sinne der Kollaboration.
Zudem brauchen Stakeholder nie(!) Zugriff auf Builds!
Worauf brauchen Sie denn beim Build Zugriff, auf Artifacts? Oder was meinst Du mit "Build" ?

Ja das wären dann wohl Artifacts. "Dat was beim Kompilieren hinten raus kommen tut".
Beispiel wäre:
Kunde hat ein Gerät, dass wir nicht in unserem Standardrepertoir haben. Ich würde das anbinden und beim Einrichten der gesamten Messstation müssen dann eben noch Dateien ergänzt werden.

Die Dateien + Informationen darüber sollen irgendwo übersichtlich zur Verfügung stehen.

Das meinte ich auch mit "Sonderlösungen".

Willkommen im Jahr 2018 🙂

Ich weigere mich! 😁

Jira ist nur ein Bug Tracking System - für Build und Co hat Atlassian andere Produkte.
.. und das kann kein Tool abdecken.
Tools wie VSTS, Jira, GitLab und Co orientieren sich an etablierten Prozessen in der Software Entwicklung - nicht an Sonderlösungen bzw. historisch gewachsene Prozesse 😉

Jira ist doch auch ein Projektmanager im Sinne des Planens und Verwaltens.

Eventuell ja eine Kombination aus Gitlab und damit verbundenem Redmine?

Ja das wären dann wohl Artifacts. "Dat was beim Kompilieren hinten raus kommen tut".

Ein Build hat genau eine Aufgabe: erzeuge ein Artifact.
Beispiel: Nimm den Quellcode von Git und mach daraus eine Exe.

Dieses Artifact landet dann auf einem sogenannten Artifact Staging (Directory).
Das ist ein Ort, an dem von jedem Build die Resultate abgelegt werden - darauf hat niemand, absolut niemand Zugriff - ausser ein Release System.

Das Release System ist nun verantwortlich ein vorhandenes Artifact zu nehmen, und an ein oder mehrere Ziele zu verschieben.
Diese Verteilung kann entweder sequentiell sein (zB. erst DEV, dann TEST, dann PROD) pder parallel, dass ein Artifakt vielen Kanälen gleichzeitig zur Verfügung gestellt wird - oder im Mix.

Beispiel:
Ich hab ein Artifact einer Webanwendung, und das Release System sorgt nun dafür, dass dieses Artifact auf einen Webserver kopiert und die Anwendung gestartet wird.
Dabei unter der Beachtung, dass es mehrere Environments geben kann, zB DEV - TEST - PROD.
Das bedeutet, dass die Settings einer Anwendung so gestaltet sein müssen, dass die Anwendung nicht neu gebaut wird, nur weil sich die Umgebung (DEV>TEST) ändert.

Warum:
Ein Artifakt ist ein isoliertes Gut.
Nur weil das Artifakt nun wo anders betrieben wird, muss es nicht neu gebaut (und getestet) werden.

Daher:

• Build erzeugt das Artifact
• Release verteilt das Artifact

Wenn Du also das Artifakt anderen zur Verfügung stellen willst: dann über ein Release.
Das Release kann auch eine E-Mail versenden, irgendwas auf ein FTP kopieren: alles.
Das muss alles pro-aktiv durch Deine Definition passieren. Es gibt kein DevOps Portal das dafür gedacht ist, dass hier irgendwelche Leute durch einen "Artifact Store" klicken.

Ein Release kann aber auch durchaus eine eigene Applikation starten, die dann zB automatisiert irgendwelche Dokumente zusammen packt und zur Verfügung stellt.

Prinzipiell geht es aber in einer solchen Pipeline immer darum, deterministische Resultate abzuliefern.
Daher auch die Trennung der Verantwortung zwischen Build und Release.

Die Dateien + Informationen darüber sollen irgendwo übersichtlich zur Verfügung stehen.

Mir ist noch unklar, woher diese Dateien komme, wo diese Dateien abgelegt und verarbeitet werden - aber irgendwie hört sich das für mich danach an, dass dafür die Quellcode Verwaltung nicht der richtige Ort ist...?!

Dieses Artifact landet dann auf einem sogenannten Artifact Staging (Directory).
Das ist ein Ort, an dem von jedem Build die Resultate abgelegt werden - darauf hat niemand, absolut niemand Zugriff - ausser ein Release System.

Daher:

• Build erzeugt das Artifact
• Release verteilt das Artifact

Wenn Du also das Artifakt anderen zur Verfügung stellen willst: dann über ein Release.
Das Release kann auch eine E-Mail versenden, irgendwas auf ein FTP kopieren: alles.
Das muss alles pro-aktiv durch Deine Definition passieren. Es gibt kein DevOps Portal das dafür gedacht ist, dass hier irgendwelche Leute durch einen "Artifact Store" klicken.

Ein Release kann aber auch durchaus eine eigene Applikation starten, die dann zB automatisiert irgendwelche Dokumente zusammen packt und zur Verfügung stellt.

Ja genau so habe ich mir das gedacht. In meinem Vokabular waren nur Build, Release... kein Vorgang oder Prozess, sondern die Datei - mea culpa.

Der Release bei uns wäre dann das Ablegen auf einem Server sowie das Anhängen der Dateien an ein Projekt (im Sinne eines Projektes in Redmine), damit sich niemand durch den Server wühlen muss.

Mir ist noch unklar, woher diese Dateien komme, wo diese Dateien abgelegt und verarbeitet werden - aber irgendwie hört sich das für mich danach an, dass dafür die Quellcode Verwaltung nicht der richtige Ort ist...?!

Wir nähern uns, ich spür's!

Genau, das soll nicht in die Quellcode-Verwaltung.
In die Quellcodeverwaltung soll:

• Der Quellcode
• Von mir geschriebene Doku dazu

In die Projektverwaltung (Redmine, Jira..) soll:

• Pflichten/Lastenhefte
• Installations-Doku
• Anwedungsbeschreibung
• Kompatibilitätslisten
• Projektdauer
  -....
• Bei Sonderlösungen auch die "Artifacts".

Heisst also bspw.:

Ich arbeite in "dev" und merge nach "Test". Es findet ein Test-Build für das Test-Artifact statt und dieses wird nach Test-Release Regeln Released/Verteilt.

Ist damit alles dufte, wird Test nach Prod gemerged und das Prod-Release verteilt das aktuelle Test-Artifakt den Vorgaben entsprechend.

Also müssen meine Dev- und Test-Pipelines über einen Runner das Artifact erzeugen und verteilen.

Die Prod-Pipeline verteilt nur das Test-Artifact.

Wenn also jemand außer mir der Ansicht wäre, dass der aktuelle Teststand der neue Masterstand werden soll, schickt er ein Merge-Request raus.

Und dieses ganze Kompilieren, Verschicken, Verschieben läuft in GitLag über die .gitlab-ci.yml?

Hallo,

Die Dateien + Informationen darüber sollen irgendwo übersichtlich zur Verfügung stehen.

Das wäre eher etwas für ein Wiki (z.B. Confluence). Darauf können auch Stakeholder Zugriff haben (für bestimmte Bereiche).

mfG Gü

Ich arbeite in "dev" und merge nach "Test". Es findet ein Test-Build für das Test-Artifact statt und dieses wird nach Test-Release Regeln Released/Verteilt.

Prinzipiell nein.

Es gibt nur ein einziges Artifakt.
Nur das Release bestimmt, wo dieses Artifakt hin kommt - es gibt nur eines für alle Stages
(Es gibt aber Ausnahmen, die Technologiebedingt sind, sodass ein Artifakt nur auf einer Stage funktionieren kann; mobile Applikationen und Settings (zB Beta App soll auf eine andere API zugreifen als die produktive Version. Hier gibt es dann wirklich ein Artifact pro Stage - aber da kommen wir nun in spezielle Bereiche).

An für sich kommen die Settings vom Environment und sind nicht Teil des Artifakts.
Dadurch kann ein Artifakt unverändert in allen Environments agieren.
Diese Art und Weise ist auch die am Höchsten gültige - gibt aber wie gesagt Ausnahmen.

Ein "Merge" findet überhaupt nicht statt; bzw. schafft mir das Wort derzeit Probleme, was Du meinst.
Denn Merge ist ein reservierter Begriff in der Quellcode-Verwaltung bzgl. dem Arbeiten von Branches. Und die Quellcode-Verwaltung kennt die Stages nicht.

Bzgl. dem Pflegen von Releases verlassen wir nun Theorie und Praxis von CI/CD Pipelines 😃
GitLab unterstützt ein wirkliches Release Management nicht. Nur Azure DevOps hat derzeit ein solches sauberes, getrenntes System für koordinierte Releases (wobei Atlassian auch auf einem guten Weg dazu ist).
In GitLab muss man das tatsächlich im YAML definieren (wie auch bei AppVeyor und Co).

Prinzipiell nein.

Na super 😉.

Es gibt nur ein einziges Artifakt.
Nur das Release bestimmt, wo dieses Artifakt hin kommt - es gibt nur eines für alle Stages
(Es gibt aber Ausnahmen, die Technologiebedingt sind, sodass ein Artifakt nur auf einer Stage funktionieren kann; mobile Applikationen und Settings (zB Beta App soll auf eine andere API zugreifen als die produktive Version. Hier gibt es dann wirklich ein Artifact pro Stage - aber da kommen wir nun in spezielle Bereiche).

Gut, okay. Wenn die Prozedur das Artifakt entprechend verteilt, existiert in dem Git-Projekt nur ein Artifakt, aber ein neues Test-Release löscht ja nicht das alles vom Prod.-Release.

An für sich kommen die Settings vom Environment und sind nicht Teil des Artifakts.
Dadurch kann ein Artifakt unverändert in allen Environments agieren.
Diese Art und Weise ist auch die am Höchsten gültige - gibt aber wie gesagt Ausnahmen.

Ein "Merge" findet überhaupt nicht statt; bzw. schafft mir das Wort derzeit Probleme, was Du meinst.
Denn Merge ist ein reservierter Begriff in der Quellcode-Verwaltung bzgl. dem Arbeiten von Branches. Und die Quellcode-Verwaltung kennt die Stages nicht.

Wa..?

https://gitlab.cern.ch/help/ci/environments.md

Die Stages sind doch die Schritte der Pipeline oder nicht?
Ich habe drei Branches: Alpha, Beta, Prod
Außerdem drei Stages: test, build, deploy
Und zwei Environments: Intern, Extern

Bei jedem Push in jedem Branch läuft die Pipeline an -> und abhängig vom Branch werden doch dann im deploy-stage die Parameter aus dem Environment geladen und entsprechend released?

Also hätte ich oben statt "merge" "push" schreiben sollen?

Bzgl. dem Pflegen von Releases verlassen wir nun Theorie und Praxis von CI/CD Pipelines 🙂
GitLab unterstützt ein wirkliches Release Management nicht. Nur Azure DevOps hat derzeit ein solches sauberes, getrenntes System für koordinierte Releases (wobei Atlassian auch auf einem guten Weg dazu ist).
In GitLab muss man das tatsächlich im YAML definieren (wie auch bei AppVeyor und Co).

Ich hab nur teilweise das Gefühl, die ganze Konfiguration pro Projekt länger dauert, als das eigentliche Projekt 🤔 😄.

Die Stages sind doch die Schritte der Pipeline oder nicht?
Ich habe drei Branches: Alpha, Beta, Prod
Außerdem drei Stages: test, build, deploy
Und zwei Environments: Intern, Extern

Stages sind Deine Environments - also Teil des Releases; nicht vom Build oder gar der Quellcode-Verwaltung
Typisch:
Ich habe eine Azure Webseite und dort drei Environments:
Dev - Test - Prod.

Siehe Beispielbilder (mit Absicht extern verlinkt):
https://docs.microsoft.com/en-us/azure/devops/pipelines/release/_img/what-is-release-management/understand-rm-01.1.png?view=vsts
https://i.ytimg.com/vi/zSPuRXTeZW8/maxresdefault.jpg

Environments sind aber niemals ein Branch! Das sieht der GitHubFlow (und alle anderen großen Flows) niemals vor.
Im Prinzip gibt es hier (im GitHubFlow) nur ein master und viele feature-Branches. Ein Vorgehen von Branches nach Environments ist falsch.
Die Quellcode-Verwaltung - und damit Git und Co - dürfen nichts von den Stages wissen.

Ich hab nur teilweise das Gefühl, die ganze Konfiguration pro Projekt länger dauert, als das eigentliche Projekt

Ich habe einen Baukasten von YAML Files (für Azure DevOps).
Brauche dadurch keine 2 Minuten um eine vollständige CI/CD Pipeline für Angular, .NET Core, ASP.NET Core oder mobile Applikation aufzubauen.

Aber hier geht halt viel Zeit drauf, weil Du erst mal DevOps und die (best practise) Prozesse verstehen magst - und die verwenden halt auch die Tools.
Ein solches Tool, sei es Azure DevOps, GitLab und Co wird Dir nur helfen, wenn Du auch Deine Prozesse transformierst.
Keines dieser Tools kann Deine aktuellen Prozesse abdecken.

Willst / musst Du Deine Prozesse behalten, dann wirst Du überall (enorme) Kompromisse machen müssen.

Aber die Stages wissen schon von den Branches/einem Branch?

Ich kann ja dann beliebig viele Feature Branches aufmachen, meine Pipeline drüber laufen lassen und jeder Branch wird nach den Variablen des Environments z.B. intern Released - der Master Branch würde aber dennoch gesondert behandelt werden, weil ein Environment für andere Branches gar nicht erreichbar wäre?

Und die Feature Branches könnte man über "merge" dann zusammenführen, die einzel-Branches + ausgelieferte Dateien löschen?

Aber die Stages wissen schon von den Branches/einem Branch?

Nein. Ein Release kennt nur ein Artifact und schiebt dieses von Environment zu Environment.

Ich kann ja dann beliebig viele Feature Branches aufmachen, meine Pipeline drüber laufen lassen

Nein, generell macht man eigentlich nur ein Release auf den master Branch; nur in besonderen Ausnahmen auf Pull Requests.

Das Release Management darf genauso wenig interessieren, wie Du Deine Branches organisierst wie das Build System nicht wissen soll, welche Environment Du hast.

Das Deployment auf Dev passiert i.d.R. mit einem automatisch Trigger.
Das bedeutet, sobald der master Branch erfolgreich gebaut wurde, wird das Artifact auf Dev deployed.

Wenn der Entwickler dann mit Dev zufrieden ist, dann erfolgt ein manuelles Deployment auf Test.
Wenn er damit ebenfalls zufrieden ist (bzw. wird Test zB verwendet, dass jemand anders als der Entwickler testen kann, zB der Kunde) dann erfolgt das Deployment auf Produktiv.
Das Artifakt dabei wird selbst NICHT neu erzeugt (sofern möglich).

Danke für die Grafik.

Nein, generell macht man eigentlich nur ein Release auf den master Branch; nur in besonderen Ausnahmen auf Pull Requests.

Das Deployment auf Dev passiert i.d.R. mit einem automatisch Trigger.
Das bedeutet, sobald der master Branch erfolgreich gebaut wurde, wird das Artifact auf Dev deployed.

Wenn der Entwickler dann mit Dev zufrieden ist, dann erfolgt ein manuelles Deployment auf Test.
Wenn er damit ebenfalls zufrieden ist (bzw. wird Test zB verwendet, dass jemand anders als der Entwickler testen kann, zB der Kunde) dann erfolgt das Deployment auf Produktiv.
Das Artifakt dabei wird selbst NICHT neu erzeugt (sofern möglich).

D.h. der Quellcode wird garkeinem Environment zugeordnet, die Zugehörigkeit basiert rein darauf, dass der Masterbranch zum aktuellsten Deployment gehört, egal ob Dev, Test oder Prod?

Hallo Gimmick,

der Quellcode wird garkeinem Environment zugeordnet

Der Quellcode ist "neutral". Die Anpassung an die Environment passiert via Konfiguration.

dass der Masterbranch zum aktuellsten Deployment gehört, egal ob Dev, Test oder Prod?

Drück es umgehrt aus: aus dem Masterbranch wird ein Artefakt (Komponente, Anwendung, ...) erstellt und dieses Artefakt wird an die Environments wie Dev, Test und Prod weitergereicht (ohne dabei verändert zu werden, siehe Konfig).

mfG Gü

Hi Gimmick,

um es vielleicht mal mit einem anderen Ansatz zu erklären.

Die willst 3 Quellcode Branchen hab. (Dev, Main, Release)

Ich gehe jetzt einfach mal davon aus, Dev ist deine Brache in der du Features für die Zukunft Entwickelst. Da sind teils Features, drin die noch nicht Komplett Fertig sind. Oder wo ungewiss ist ob sie in der Form wirklich auf Markt kommen. Da soll dann die QS noch mal drüber schauen. Und man kann es vielleicht einigen Kunden schon mal zeigen oder auf Messen vorführen.

Main könnte deine Branche sein, wo feststeht, das ist der nächste „Main“ Release Stand. Da sind neue Features drin, die Schon Fertig sind. Und sie wurde vielleicht ein paar Test Kunden zu Verfügung gestellt.

Und Release ist die Brache, die (in der letzten Version) zu Kunden ausgeliefert wurde. Da trete noch Fehler auf, die müssen dann Möglichst schnell behoben werden. Um dann natürlich Möglichst schnell zum Kunden zu kommen.

Dann kannst (musst aber nicht) du für alle 3 ein Dev, Test und Release Environment haben. Klingt jetzt erst mal schlimmer als es ist. Es ist größten teils Automatisiert und meist sind es nur Kleinigkeiten die sich ändern wie z.B. die Datenbank (lässt sich gut Automatisieren, du muss zwischen Dev und Test Environment nur eine Variable ändern, damit da Verschiedene Datenbanken verwendet werden. (Ich erkläre es hier einfach mal an Hand der DB, ich denke das ist am leichtesten nach zu vollziehen. Es gibt aber auch noch andere Gründe)

Also erst mal das einfachere. Wie so brauche ich zwischen den Quellcode Branches unterschiedliche Environments. Nun meist haben neue Features, auch den bedarf nach neuen Datenbank Feldern. Oder Brauchen neue Tabellen. (Wie gesagt ich mach es jetzt mal über die DB schiene). Die Dev Branche kann dann nicht mit der DB von Main Funktionieren und Main nicht mehr mit Release.

Das das bisschen Kompliziertere (kein muss). Du (kann bei der Dev Enviorment auch jemand anders sein als du) kannst als Entwickler einfach nicht alles Testen, dafür gibt es ja auch die QS. Du möchtest dann möglichst bei den Daten mit denen du testet, die du als Problematisch ansiehst. Bei der QS sieht es da schon ein bisschen anders aus. Die möchten lieber Daten die näher an Realen System vom Kunden dran sind. Und zum Schluss ist da natürlich der Kunde, der hat reale Daten. Und selbst bei der (Quellcode) Dev Branche, kann es sein das man sich da Daten vom Kunden besorgt. Damit die Kunden auf der Messe das Gefühl haben sie „Arbeiten“ an einem Realem System.

Wie sieht da dein Arbeitsprozess aus. (Ich mach es einfach mal am Beispiel von der Release Branche, bei anderen Branchen kann ein Fehler auch einfache ein Änderungswunsch oder ein neues Feature sein und betrachtet nicht alle möglichen Optionen).

Du gehst hin und Behebst einen Fehler. Der Gemeldet wurde last bei dir die UnitTest laufen. Und Checkst die Änderungen ein, wo bei du den Checkin mit dem Fehler verknüpfst, so das man später sehen kann welcher Fehler damit verbunden ist. Der CI Build mit UnitTest wird gestartet und du bekommst automatisch ein Feedback, das es nicht nur auf deinen Rechner Funktioniert. Sondern auch auf dem „Dev Test System“. Nach dem du „alle“ (können auch nur die dringendsten sein) Fehler behoben haste. Sagst du Bescheid (kann auch Automatisch passieren). Wird ein Build erzeugt, der (dessen Artefakt) Automatisch in die „Dev Envirorment“ geschoben wird. (Hier werden dann teilweise, noch Automatisch Integartionstest und Coded UI Test ausgeführt). Der Verantwortlich (kannst auch du sein) das die Software (das Artefakt), den Qualitätsansprüchen genügt. (Je nach Vorgabe kann man da auch noch ein paar Manuelle Test machen Und gibt dann frei das (Artefakt) es in der „Test Environment“ landet. (Was größtenteils Automatisch passiert). In der QS wiederholt es sich dann mit dem Testen und der Freigabe. (Nur die haben halt ein anderes Environment) und dann geht es weiter mit dem Release.

Für mich ist der Punkt, das ich das Vorgehen durchaus für sinnvoll halte. Und das was bisher möglich ist möglichst Automatisiert wurde.

Ja man muss es einrichten und es ist auch mit einem gewissen Aufwand verbunden. Danach muss man aber meist einfach nur ein paar Variablen ändern.

p.s.
Ja es ist schlampig geschrieben und ich hab nur die Aus meiner Sicht wichtigen Punkte angesprochen.

Der Quellcode ist "neutral". Die Anpassung an die Environment passiert via
> .

Drück es umgehrt aus: aus dem Masterbranch wird ein Artefakt (Komponente, Anwendung, ...) erstellt und dieses Artefakt wird an die Environments wie Dev, Test und Prod weitergereicht (ohne dabei verändert zu werden, siehe Konfig).

In dem Fall hätte man aber kein Backup des Codes, aus dem der aktuelle Prod-Stand erstellt wurde.

Hi Gimmick,

um es vielleicht mal mit einem anderen Ansatz zu erklären.

Die willst 3 Quellcode Branchen hab. (Dev, Main, Release)

[...]

Dann kannst (musst aber nicht) du für alle 3 ein Dev, Test und Release Environment haben.

[...]

Erstmal danke für den umfangreichen Post.

Wenn ich nicht jeweils drei eigene Environments hätte, müsste ich aber in der Pipeline prüfen, in welchem Branch ich gerade bin, damit das Main-Artifact nicht nach dem Prod/Release-Release-Prozedere veröffentlicht wird.

Und das meinte ich damit, dass die Environments ja quasi von den Branches wissen müssen.

Wenn ich hingegen drei Branches anlegen, würde ich ja doch mein Release über die Branches oragnisieren - und darf man doch nicht ^^.

In dem Fall hätte man aber kein Backup des Codes, aus dem der aktuelle Prod-Stand erstellt wurde.

Doch. Dafür hast Du ja Dein Git Repository.
Und ein Release ist immer mit einem Git Commit getaggt.

Das Grundproblem ist meiner Ansicht nacht immer noch, dass eure internen Prozesse mit einem modernen DevOps Prozess und den Mechanismen in einem Release System nicht im Einklang stehen.

Du gehst hin und Behebst einen Fehler. Der Gemeldet wurde last bei dir die UnitTest laufen. Und Checkst die Änderungen ein, wo bei du den Checkin mit dem Fehler verknüpfst, so das man später sehen kann welcher Fehler damit verbunden ist. Der CI Build mit UnitTest wird gestartet und du bekommst automatisch ein Feedback, das es nicht nur auf deinen Rechner Funktioniert. Sondern auch auf dem „Dev Test System“. Nach dem du „alle“ (können auch nur die dringendsten sein) Fehler behoben haste. Sagst du Bescheid (kann auch Automatisch passieren). Wird ein Build erzeugt, der (dessen Artefakt) Automatisch in die „Dev Envirorment“ geschoben wird. (Hier werden dann teilweise, noch Automatisch Integartionstest und Coded UI Test ausgeführt). Der Verantwortlich (kannst auch du sein) das die Software (das Artefakt), den Qualitätsansprüchen genügt. (Je nach Vorgabe kann man da auch noch ein paar Manuelle Test machen Und gibt dann frei das (Artefakt) es in der „Test Environment“ landet. (Was größtenteils Automatisch passiert). In der QS wiederholt es sich dann mit dem Testen und der Freigabe. (Nur die haben halt ein anderes Environment) und dann geht es weiter mit dem Release.

Davon abgesehen, dass dies kein roter Faden durch DevOps wäre: das Ergebnis wäre aber kein deterministisches.
Das gilt es in DevOps zu vermeiden.

Doch. Dafür hast Du ja Dein Git Repository.
Und ein Release ist immer mit einem Git Commit getaggt.

Achso, ich dachte das würde immer überschrieben werden.

Das Grundproblem ist meiner Ansicht nacht immer noch, dass eure internen Prozesse mit einem modernen DevOps Prozess und den Mechanismen in einem Release System nicht im Einklang stehen.

Davon abgesehen, dass dies kein roter Faden durch DevOps wäre: das Ergebnis wäre aber kein deterministisches.
Das gilt es in DevOps zu vermeiden.

Ne, das ist nicht das Grundproblem.

Es geht hier ja rein um das Verständnis des vorgesehenen Prozesses und vorallem um die reale Umsetzung davon mit Git - von null. Was muss ich wo einstellen, was macht die Pipeline konkret und wie sieht der tatsächliche Release-Prozess aus. Der reale Prozess hat damit erstmal nichts zu tun.
Das Zusammentreffen mit der Realität folgt erst noch.

Ich finde die ganze Sache schon rein von den Begriffen verwirrend.
Der Hinweis mit den Tags war gut.

Ich muss jetzt mal Zeit finden und mein Gitlab nach den Prinzipien einstellen. Dann wieder im Kleinen testen.

Ich seh die Probleme bei der Pipeline schon - ich melde mich dann 😄.

Der Hinweis mit den Tags war gut.

Das Taggen von Commit IDs ist was anderes als Git Tags - nicht verwechseln.
Das eine ist eine Sache, das andere ein Git Feature.

Du musst Dir vielleicht das ein oder andere Grundkonzept intensiver anschauen, sodass die Begrifflichkeiten klar werden.

Nur mal ein Update:

Die Arbeit mit einer Kombination aus Gitlab und Redmine hat sich bisher bewährt. Eure Posts haben sehr geholfen, danke.