Wir verwenden Mercurial jetzt seit ein paar Monaten und es hat unseren Bereitstellungsprozess bereits um ein Vielfaches verbessert. Das ist der gute Teil.
Das System, das wir haben, funktioniert, ist aber immer noch fehleranfällig, wenn man nicht aufpasst oder sich beeilt. Deshalb frage ich mich, ob es Möglichkeiten gibt, es zu verbessern, oder... vielleicht sind wir völlig vom Weg abgekommen :)
Unser Umfeld besteht aus:
- Lokaler Entwicklungsarbeitsplatz (jeder Entwickler)
- Entwicklungsserver (Hosting der DB und des zentralen Repository)
- Ein Abnahmeserver (wo die QA durchgeführt wird)
- Ein Staging-Server (auf dem wir den Versionszweig bereitstellen, den wir dann per Robocopy auf die Live-Systeme übertragen)
Ein wenig Hintergrundwissen über den Grund, warum wir gewechselt haben:
In unserem Arbeitsumfeld wechseln wir oft von einer Aufgabe zur nächsten, so dass viele Aufgaben unerledigt bleiben. Viele davon würden veralten und den Hauptzweig verstopfen, wenn wir wieder im CVS sind. Das Deployment war ein Albtraum, da man mit Beyond Compare um die Zeilen herumarbeiten musste, die live gehen sollten, und andere, die es nicht taten.
Mercurial mit benannten Zweigen und einfacher Zusammenführung löst dieses Problem für uns. Wir wussten also nicht, was uns erwartete, und richteten es ein.
Zunächst haben wir unsere Produktionsquelle bereinigt, indem wir tote Dateien entfernt haben usw.
Wir FTP'd, dass auf Staging und machte diese unsere neue Repository als "Standard", das war unser stabiler Zweig bereit zu sein, jederzeit bereitgestellt werden.
Danach haben wir eine hg clone auf den Entwicklungsserver und ließ jeden Entwickler hg clone aus dem Standardentwicklungszweig.
Bei der Abnahme, bei der wir die QA durchführen, haben wir eine hg clone des Standardzweigs des Entwicklungsservers.
Zu diesem Zeitpunkt haben wir überall eine stabile Kopie des Codes, jeder ist begierig darauf, zu beginnen!
lokalen Rechner sind Schieben zu dev, Akzeptanz zieht von Dev und Staging ist vollständig isoliert und kann von überall her kommen, wenn der Pfad angegeben ist.
Die Idee dahinter war, dass der Standardzweig auf unserem System immer eine Kopie des Codes auf dem Live-Server sein würde, vorausgesetzt, dass wir daran denken, einen neuen Zweig zu ziehen, bevor wir einen neuen beginnen. Wenn wir ein neues Feature starten, würden wir:
hg pull -b default #synch up
hg update default
hg branch {newFeature} #newFeature completely isolated from other changes.
*work on {newFeature}Oh nein! Ein Fehler! Das hat nichts mit dem zu tun, woran ich gerade arbeite, nennen wir es {bugFix111}. Dies scheint eine neue Verzweigung unabhängig von meiner Funktion zu erfordern; gehen Sie zurück zum aktualisierten Standard. Dadurch werden newFeature und bugFix111 voneinander isoliert und können unabhängig voneinander in Betrieb genommen werden, da sie auf default basieren.
hg update default
hg pull -u
hg branch {bugFix111}Sobald die Arbeit an, sagen wir, {bugFix111} abgeschlossen ist
hg push -F {bugFix111} #send our fix to the main central repo on dev. Gehen Sie zur Annahme:
hg pull -b {bugFix111} #pull the fix from the central repo (dev).
hg merge {bugFix111} #merge the code in the default QA branch.
hg commit -m "Merging {bugFix111} into default"
*QA sign off on the fixWir müssen von der Abnahme abzweigen - Standard, wo die Qualitätssicherung stattfindet, und Freigabe, wo wir das Material zusammenführen, wenn es abgezeichnet wird.
hg update release
hg merge {bugFix111} #fix is now ready to go live
hg commit -m "Merging {bugFix111} into release"Zur Inszenierung:
hg pull -b release {PATH TO ACCEPTANCE REPO}
hg merge release
hg commit -m "Merging {bugFix111} into staging default"
hg tag release{date}
*robocopy to live
*run task that pull from staging to dev so that they synch up again.Das hat sich für uns bewährt und spart Zeit bei der Bereitstellung, da es ein Kinderspiel ist, einfach den stabilen Release-Zweig zu kopieren.
Ausgaben
Was wir festgestellt haben, ist:
-
Es ist leicht, eine Zusammenführung zu vermasseln, wenn man zum zweiten Mal bei der Veröffentlichung zusammenführt, und das scheint gegen den Fluss zu sein. Wir können es nach der Freigabe durch die QA abbrechen.
-
Könnte QA dazu bringen, unseren Release-Zweig ebenfalls zu testen, aber es scheint, als würden wir Ressourcen verdoppeln, die Ziel ist es, die Funktionen zu isolieren und sie nacheinander zu senden. .
-
Wir können es komplett vermasseln, indem wir release über etwas Falsches zusammenführen, z.B. überschreibt hg merge release, wenn Sie auf der Standardannahme sind, diese komplett.
-
Wenn wir vergessen, vor dem Start eines neuen Zweigs einen Pull zu machen, arbeiten wir auf der falschen Basis.
-
Ein paar andere Merkwürdigkeiten, aber das sind die größten Hürden.
Mir ist klar, dass dies ein langer Beitrag ist, aber ich hoffe, dass die Antworten anderen Mercurial-Neulingen wie mir helfen werden, die versuchen, einen vernünftigen Arbeitsablauf in ihrem Unternehmen einzurichten.
