Code soll erst auf Devops eingecheckt werden, wenn er buildet.

Azure DevOps hat ja genügend Einstellungen, die man machen kann, um den Code Build zu testen, automatisch ausführen zu lassen, sich berichtigen zu lassen usw.

Thema:

Azure DevOps hat ja genügend Einstellungen, die man machen kann,
um den Code Build zu testen, automatisch ausführen zu lassen,
sich berichtigen zu lassen, usw.

Bei uns wird nach einer Möglichkeit gesucht, den Code gar nicht erst auf DevOps einchecken zu lassen,
bevor er nicht eindeutig kompiliert.

Kennt dafür jemand eine Möglichkeit?

Denn im Moment wüsste ich nicht, wie man das erreicht.

Gewollt ist quasi folgender Mechanismus:

1.) Es wird versucht, einzuchecken. Auf ein DevOps Repository.
2.) Dann soll DevOps (wie auch immer) den Build überprüfen.
3.) Und wenn der erfolgreich war, erst DANN das Ganze ins Repository übernehmen.

Ich wüsste nicht, dass DevOps das so von Haus aus kann.
Und wenn, dann fällt mir da nur was Ähnliches wie ein Buildvorgang ein, der aus 2 Pipelines besteht
oder eine Lösung mit einem lokalen Agenten, aber auch das ist nicht gewollt.

Meine Lösung dazu:

Ich hatte dann vorgeschlagen, dass jeder Entwickler das gleiche Tool nehmen kann,
dass das schon in der IDE so wäre.
Problem gelöst.
Nur … leider wird das nicht akzeptiert. Da das ja dann lokal wäre …

Ich entscheide bedauerlicherweise nicht selbst, welche Lösung wir favorisieren.
Kann darüber nicht bestimmen.

Wie würdet ihr das machen? Geht das überhaupt mit Azure DevOps Boardmitteln?

Wie würdet ihr das machen? Geht das überhaupt mit Azure DevOps Boardmitteln?

Gar nicht - und gut, dass das auch nicht in solchen Tools eingebaut ist.
Selbst lokale Git Hooks kann man Gott sei dank jederzeit deaktivieren.
Daher das Fazit: nein, so ein Mechanismus ist in keiner Umgebung möglich.

Code muss immer eingecheckt sein, damit ein solches System dieses builden kann.

Warum darf nur Code eingecheckt werden, der buildet, wo ist der Sinn?
Wenn ich spontan los muss, aber Code noch einchecken will - dann hindert mich das Tool daran.

Es macht sinn, dass ein gewissen Branch immer buildet (zB main) - aber nicht generell, dass jeder Checkin builden muss.
Genau für die Qualitätssicherung gibts aber Branching-Mechanismen wie eben den GitHub Flow, GitLab Flow oder klassischer der GitFlow und am Ende Pull Requests.
Aber einen Developer vorzuschreiben, dass er nur buildenden Code in seinen/ihren Branch zu pushen: organisatische Fehlleistung, Developer-Gängelung.

Ich verstehe das Ziel dahinter, aber das würde ich auch nicht technisch erzwingen, sondern eher "soft" im Team.

Z.B. hatte ein ehemaliger Arbeitgeber von mir dafür eine kleine Tradition.
Jeder CheckIn hat einen Build angestoßen und wenn der ohne Fehler durchlief, wurde nur der Urheber informiert, wenn nicht, wurden alle informiert.
Derjenige, der zuletzt den Build "kaputt gemacht" hat, hat dann einen Plüsch-Earny als zweifelhafte Trophäe samt feierlicher Übergabe erhalten, den er solange bei sich auf dem Platz sitzen lassen musste, bis jemand Anderes den Build "kaputt gemacht" hat.

In dem Team haben es alle mit Humor genommen und mit der Zeit haben sich alle daran gewöhnt, ihre Arbeit nochmal zu kontrollieren und auch vor Feierabend darauf zu achten.
Sollte es nicht gehen (z.B. weil wirklich etwas dazwischen kam und dann nur halb-fertiger Code da war), haben viele die ShelveSets vom TFVC genutzt - die Funktion vermisse ich auch ein bisschen bei Git, die Stashes werden ja nicht auf dem Server gespeichert.

Würde es dir reichen wenn der Code nur in den Hauptbranch gemergt werden darf, wenn er buildet?
Dann musst du lediglich:

• Pipeline erstellen die den Code buildet
• im Haupt-Branch die Policy aktivieren, dass die vorher erstellte Pipeline erfolgreich durchlaufen werden muss

Schon kannst du nur noch Pull Requests mit "buildbarem" Code abschließen.

Derjenige, der zuletzt den Build "kaputt gemacht" hat, hat dann einen Plüsch-Earny als zweifelhafte Trophäe samt feierlicher Übergabe erhalten, den er solange bei sich auf dem Platz sitzen lassen musste, bis jemand Anderes den Build "kaputt gemacht" hat.

Kenne solche Traditionen auch, zB mit Pfannen, Fahnen, Mützen...

Aber bei Teams, die mit ordentlichen Pull Request Policies arbeiten, kann das ja (eigentlich) nicht mehr passieren.

@Abt.

Wie ich ja gesagt hatte, ich hätte es auch anders vorgeschlagen. Da ich derselben Meinung war, dass das unsinnig ist.
Nur … ich bin leider nicht derjenige, der es bestimmt. Sondern jemand anders höher in der Hierarchie.

Ja, die Absicht ist erkennbar.
Nur bedauerlicherweise akzeptiert diese Person keine andere Lösung.

und ich sehe das auch als organisatorische Fehlleistung, Gängelung. Trägt einfach nicht zur Produktivität bei. Im Gegentil.

dr4g0n76

War auch als Unterstützung für Dich gedacht 🙂

Ich finde den Vorschlag von dannoe sinnvoll. Schlag das doch mal vor.