Automatisierung des Workflows eines kleinen Entwicklungsteams (Teil 1)

An fast allen Stellen meiner Arbeit als Entwicklungsprogrammierer habe ich nur zwei Produkte verwendet: Fehlerverfolgung und Versionskontrollsystem. Am häufigsten waren dies Atlassian Jira und SVN. Das Vorhandensein dieser beiden Systeme rationalisiert im Prinzip die Kommunikation aller am Entwicklungsprozess Beteiligten und wirkt sich positiv auf die Arbeitsqualität der Abteilung und des Produkts aus.

Vor ca. 4 Jahren bin ich mental und dann tatsächlich auf die Ebene der Teamleitung angewachsen. Die Ansichten sind breiter und höher als die aktuellen Prozesse. Über Motivation, Optimierung, Automatisierung und andere Aspekte kamen verschiedene Gedanken in den Sinn. In diesem Artikel möchte ich Erfahrungen aus der Kategorie der technischen Kompetenzen des Teams mitteilen: Wie automatisiere ich tägliche Prozesse (z. B. automatische Montage eines Produkts, Layout, Dokumentation, Rechteverwaltung usw. usw.)?

Nach der dritten Seite meines Artikels habe ich beschlossen, ihn in zwei Blöcke zu unterteilen:


Also Einrichten von Software, die den Entwicklungsprozess begleitet




Menschenmenge und Jira


Der erste war Crowd, der Account Manager. Ich habe es mit Jira gekreuzt und synchronisiert. Die Menge hat alle Gruppen und alle Jira-Benutzer angezogen. In Jira habe ich Lese- / Schreibvorgänge mit dem Crowd-Verzeichnis durchgeführt (da es bequemer ist, einen neuen Benutzer über Jira als über Crowd hinzuzufügen).
In Jira wurden alle Benutzer in Gruppen unterteilt:

  • Jira-Benutzer.
    Obligatorische Gruppe für alle Benutzer.
  • Jira-Entwickler
    Eine Gruppe von Programmierern, Testern, Analysten und technischen Tees. Im Allgemeinen für diejenigen, die direkt an der Entwicklung beteiligt sind.
  • project1-users
    Jeder, der mit project1 in Verbindung steht. Kunde, Management (zur Überwachung des Prozesses), das gesamte Projektteam.
  • Projekt1-Entwickler.
    Nur die Entwickler dieses Projekts.

Jira bietet Ihnen in jedem Projekt die Möglichkeit, 3 Rollen zu konfigurieren. Ich brachte die Gruppe project1-users in die Rolle USERS, project1-developers in die Rolle DEVELOPERS und PM (Projektmanager) in die Rolle ADMINISTRATORS.

Kurz gesagt, die Benutzer in der Gruppe können nur Aufgaben erstellen und beobachten, Entwickler können sie bearbeiten und lösen und Administratoren können Versionen und Komponenten verwalten, Kommentare oder Aufgaben anderer Personen löschen oder bearbeiten.

Zusammenfluss


Ich halte dieses Produkt für die erfolgreichste Wissensdatenbank aller Art. Nachdem ich eine große Anzahl von Artikeln gelesen und verschiedene Systeme verglichen hatte, kam ich zu dem Schluss, dass Confluence der unbestrittene Marktführer unter ihnen ist.

Darin habe ich verschiedene Spaces erstellt:

  • Org Fragen.
    Allgemeine Informationen zum Betrieb des Unternehmens (FTP-Speichereinstellungen, WLAN, Regeln für die Bezahlung von Überstunden, Urlaubsabrechnung, Mitarbeiterkontakte, Unternehmensgespräche, Anweisungen zum Anschließen eines Druckers usw. usw.)
  • Entwicklung und Administration.
    Technische Informationen zur Unterstützung des Entwicklungsteams (Regeln für das Entwerfen, Auslegen und Kommentieren des Codes, alle Arten von Nuancen in der Serververwaltung, Verwendung aufwändiger Entwürfe von Programmiersprachen). Die ganze Erfahrung, auf was sie gestoßen sind, stieß und gewann für eine lange Zeit.
  • Platz für jedes Projekt.
    Alles, was in der vorherigen Gruppe nur mit diesem Projekt zu tun hat (Krückennuancen, nützliche SQL-Abfragen), User Stories, Produktionen, eingehende Daten (Designs, Logos, Symbole, Zugriffsparameter), ausgehende Daten (Readme, Anweisungen, Versionshinweise), Testpläne , Beschreibung von Mechanismen, Modulen usw. usw.

Das Wichtigste und Angenehme ist, dass Confluence eigenständige HTML-Seiten in alle Artikel exportieren kann.

Die gesamte Hilfe wird in Confluence in Form einer hierarchischen Artikelstruktur gespeichert. Am Ende der Version erhalten Sie mit einem Klick eine Reihe von HTML-Dateien, die miteinander verknüpft sind. Wir kopieren einfach all dieses Vergnügen in das Projekt und lassen es raus. Und deshalb ist unsere Hilfe paginiert (und nicht nur in einer großen Datei), einfach zu pflegen und immer online für das gesamte Team verfügbar (und nicht irgendwo in einem Ordner).

Jedes Jira-Projekt und der Confluence-Bereich sind miteinander verbunden. In dem Artikel mit der Aussage gibt es einen Link zum Problem und umgekehrt.

Bitbucket


Zur Speicherung von Quellcodes haben wir in der Vergangenheit SVN verwendet. Der Einfluss neuer Technologien ging nicht vorbei, und natürlich fiel die Wahl auf git (schließlich Best Practices).

Da ich ein Programmierer und kein Sysadmin bin, habe ich die Installation eines sauberen Gits nicht gemeistert. Deshalb habe ich das fertige GitBlit-Paket genommen ... aber bald war ich davon enttäuscht. Infolgedessen wurde alles in GitLab übertragen.

Das Arbeitsjahr und 12 gleichzeitig laufende Projekte machten sich bemerkbar. Der Server begann sich unter dem Gewicht eines Rubins zu biegen. Darüber hinaus ist die sehr schwache Verträglichkeit mit Atlassian-Produkten betroffen.

Zu dieser Zeit bemerkte ich Stash. In seiner reinen Form unter Linux habe ich es leider nicht gefunden, dafür habe ich es als Teil von Bitbucket gestellt. Und los geht's!

Erstellt Projekte und ein Repository in jedem. Er gab jedem PM die vollen Rechte für sein Projekt (jetzt kann er selbst Repositorys in seinem Projekt erstellen, wie er will). Im Repository für den Master hat der Zweig nur die Lead-Rechte vergeben und standardmäßig den dev-Zweig festgelegt.

Ich habe Bitbucket mit Jira gekreuzt und jetzt gibt es in jeder Aufgabe eine Liste aller Commits für die Aufgabe. Und von komitov ist es möglich, zu Problemen überzugehen.

Fischauge und Tiegel


Ich habe irgendwo gelesen, dass Crucible in Stash eingebettet werden kann. Nachdem ich Bitbucket bereits im Detail studiert hatte, fand ich nichts Vergleichbares. Und da CodeReview ein obligatorischer Schritt in unserem Workflow ist, musste ich auch Fisheye installieren. Wirklich sehr praktisch, aber mit Bitbucket könnte man darauf verzichten.

Als wir GitLab hatten, war das Hinzufügen von Repositories zu Fisheye wirklich chaotisch ... Eine Reihe von Einstellungen, Schlüsselgenerierung, übrige Benutzer ... Mit Bitbucket lief alles wie am Schnürchen. Ich überquerte Fisheye und Bitbucket und eine Liste aller Repositories mit der Schaltfläche "Hinzufügen" erschien in Fisheye.

Er erstellte die Projekte, gab in ihnen die Entwicklerteams an, die in Jira für diese Projekte tätig waren, gab das Repository an und jeder kreuzte sein Projekt in Jira. In Jira hingegen wies er in jedem Projekt auf Links zu Fisheye und Crucible und den Pfad zum Endlager hin.

Jetzt gibt es in jeder Aufgabe Commit nicht nur von Bitbucket, sondern auch von Fisheye. Natürlich macht das keinen Sinn ... aber es ist okay. Aber in jeder Aufgabe können Sie jetzt sofort die Überprüfung und ihren Status sehen!

Jenkins


Das scheint alles zu sein, aber nein! Wow, diese ganze Farm ist irgendwie automatisiert zu sammeln. Ich wollte schon sehr lange Bamboo ficken, aber im Vergleich zu Jenkins sieht es mangelhaft aus. Bei Jenkins konnte ich auch die automatische Montage mit Perlmuttknöpfen einrichten. Im Bambus ist das nicht so. Die Community ist schwach, es gibt nur wenige Plugins, die Sie nur durch Ausführen von Konsolenbefehlen steuern können. Ich werde die Mängel nicht auflisten. Am Anfang habe ich Delphi-Projekte für die Assemblierung eingerichtet, dann bin ich ins Web gewechselt und Assemblierungen wurden einfach - ich habe sie herausgezogen, auf ftp hochgeladen, in Jira markiert und die Briefe gesendet. Ich denke, vielleicht gehen wir zu Bamboo.

Also hat Jenkins mit niemandem gekreuzt. Es scheint, als gäbe es keine Notwendigkeit. Niemand interessiert sich für das Problem, wie oft sie sich getroffen hat. Das Einzige ist, dass Jenkins das Jira-Plugin in Jenkins selbst installiert hat, sodass beim Erstellen von Aufgaben automatisch ein anderer WorkFlow-Schritt ausgeführt wird.

Und es ist wichtig, dass alle oben genannten Produkte auf Crowd konfiguriert werden. Eine einheitliche Buchhaltung in all diesen Systemen ist sehr praktisch. Wenn Sie ein neues Teammitglied einstellen, reicht es aus, ihn in Jira zu holen und ihm sein Projektteam mitzuteilen, und er hat Zugriff auf alles. Ebenso bei Entlassung. An einer Stelle habe ich es ausgeschaltet und es gibt nirgendwo Zugang.

Sysadmin's Ecke


Der Server, den wir haben, ist Xeon X3430 4CPUs x 2,4 GHz, 8 GB, 1 TB.

Zuerst habe ich Windows Server und all diese Produkte auf einmal aufgegriffen + Ubuntu für GitLab. Der Server hat es nicht geschafft, alle zwei Stunden hing er nur 10 Minuten lang.
Danach entschloss ich mich, mich durch verschiedene virtuelle Maschinen zu teilen. Folgendes ist passiert:

Gateway - um auf das Internet zuzugreifen (4 Kerne, 4 GB RAM) - Ich habe diese virtuelle Maschine bereits vom Administrator erhalten, den dieser Server ursprünglich eingerichtet hat.
Jira - 2 Kernel, 2 GB RAM
Confluence - 2 Kernel, 2 GB RAM
Bitbucket & Jenkins - 2 Kernel, 2 GB RAM
Crowd & FishEye & FTP - 2 Kernel, 2 GB RAM
Alle virtuellen Maschinen unter Linux Debian 8.2

Jetzt fliegen alle diese Produkte, und es gibt nach wie vor keine Einfrierungen.

Auf der virtuellen Gateway-Maschine habe ich zwei Ports weitergeleitet, sodass Jira und Confluence von außen zugänglich sind. Ich denke darüber nach, den Port für den Zugriff auf Git weiterzuleiten. Aber um sicherer zu sein, nur SSH-Zugriff.

Zusammenfassung


Der Server und alle notwendigen Produkte für die vollständige Automatisierung der Workflow-Entwicklung sind fertig. Im nächsten Teil werde ich versuchen, detailliert zu beschreiben, wie diese Produkte täglich im Entwicklungsprozess interagieren.

PS Ich fand es unnötig, das detaillierte Setup jedes Atlassian-Produkts zu beschreiben, da der Artikel sehr lang und kompliziert werden würde. Wenn eine angesehene Community den Wunsch hat, sich mit meinen Erfahrungen vertraut zu machen, beschreibe ich gerne diese Nuancen der Einstellungen.

Jetzt auch beliebt: