Projektleitplanken: Schreiben in die Produktion

In den letzten Artikeln habe ich über ein paar Dinge gesprochen (die für das eigentliche Schreiben an die Produktion gespeichert wurden), die helfen, ein erfolgreiches Projekt durchzuführen:

1. Die Gefahren des „ Design by Committee “,
2. Überlegungen zur Bereitstellung einer Umgebung.

Als Letztes möchte ich auf das bisher Gelernte eingehen, das mich mit der Aufrechterhaltung der sprichwörtlichen Schlüssel zum Reich des Schreibens bis zur Produktion und der Frage, warum das wichtig ist, befassen möchte.

Schreiben an die Produktion

Die Idee, für die Produktion zu schreiben, mag wie die dogmatischste Leitplanke der genannten erscheinen, da sie normalerweise für diejenigen in Ordnung ist, die die Lösung erstellen, und sie wissen, wie sie funktioniert.

Die anderen Stakeholder tun dies wahrscheinlich nicht (aber wenn sie es tun und das Entwicklungsteam damit einverstanden ist, dass die anderen die Versionskontrolle verwenden, um dies zu handhaben, dann machen Sie es).

Wer hat wirklich die Erlaubnis, dieses Zeug zu verwalten?

Denken Sie jedoch daran, dass sich, wie bereits erwähnt , die Art und Weise, wie wir unsere Projekte bereitstellen, inzwischen geändert hat, sodass wir häufig kontinuierliche Bereitstellung und kontinuierliche Integration haben.

Und oft sind diese Dienste mit einem Quellcode-Repository wie GitHub und einem Messaging-System verbunden (das wiederum mit Slack verbunden sein kann, was ich nützlich finde).

Damit die Teammitglieder wissen, was bereitgestellt wurde und wann, und sie wissen, wie sie den Code (der aus dem Repository stammt, nicht aus dem Herunterladen über S/FTP) bei Bedarf erhalten.

Wenn ein Hotfix benötigt wird, sollte immer noch ein Verfahren vorhanden sein. Vielleicht ist jemand auf Abruf, und es gibt einen Prozess, bei dem Verzweigungen, Zusammenführungen, Markierungen und semantische Versionierung verwendet werden.

Unabhängig davon geht es nicht so sehr darum, wie der Prozess funktioniert; es ist, dass es vorhanden ist und dass es befolgt wird.

Natürlich werden diese Dinge nicht eingesetzt, um die Entwicklung komplizierter zu machen (obwohl ich verstehe, wie es so aussehen mag). Ganz im Gegenteil. Es hat verschiedene Gründe:

• Um die kontinuierliche Bereitstellung aufrechtzuerhalten, wissen Sie, kontinuierlich,
• integrierte Tests haben,
• Codierstandards oder Codequalität kontinuierlich zu messen,
• Cowboy-Codierung zu verhindern,
• und mehr.

Es geht nicht so sehr darum, andere Leute draußen zu halten, aber wenn es in der Verantwortung der Entwickler liegt, Code zu pushen, sollte dann wirklich jemand anderes Schreibzugriff auf den Server haben?

Und das ist das Endergebnis: Wenn Sie in einem Team arbeiten, in dem die von Ihnen eingerichteten Prozesse Ihre Arbeit vollständig untergraben können, was ist dann überhaupt der Zweck des Prozesses?

Denn jederzeit kann jemand anderes hinzukommen und alles, was Sie getan haben, außer Acht lassen. Sie sind dann zumindest:

• stecken damit fest, dass sie ihre Änderungen wahrscheinlich über S/FTP ziehen müssen,
• Vergleichen Sie es mit einem Diff-Tool mit einem Zweig, an dem jemand arbeitet,
• Implementieren Sie die Änderungen (um herauszufinden, warum sie vorgenommen wurden),
• und dann weiter an den Anforderungen arbeiten.

Es klingt hektisch, wenn man es so formuliert, aber genau das passiert.

Das wegnehmen

Also, was ist der ganze Zweck der letzten Posts? Wenn ich es so kurz wie möglich zusammenfassen müsste, dann wäre es:

Wenn es um ein Projekt geht, kennen Sie Ihre Verantwortlichkeiten und treten Sie nicht aus ihnen heraus. Andernfalls riskieren Sie, das Ganze zu entgleisen.

Das gilt für Entwickler, Designer, Kunden, Marketingspezialisten, Projektmanager usw. Wie die Rollen benannt sind, ist nicht so wichtig (ich meine, es ist normalerweise klar, wer in den obigen Rollen wer sein sollte), aber ich meine in Bezug auf wer die eigentliche Bezugsperson ist – der Projektverantwortliche – für das gesamte Projekt.

Sei nicht so.

Und je nachdem, wie all dies abläuft, kann das Projekt eine relativ unkomplizierte tägliche Arbeit sein.

Wollen wir nicht so viel wie möglich genießen, was wir tun?