Warum automatisieren wir die Softwareentwicklung?

Qualität ist eines der Prinzipien, die wir bei Droptica hochhalten. Wir wollen die beste Software erstellen, die den Anforderungen unserer Kunden entspricht – effizient, fehlerfrei und kostengünstig. In diesem Beitrag werde ich Ihnen von einem der entscheidendsten Faktoren berichten, der die Qualität der von uns entwickelten Software beeinflusst – die Automatisierung des Softwareentwicklungs-Prozesses.

Wir sind begeisterte Verfechter der Automatisierung. Im Laufe der letzten zehn Jahre hatten wir viele Gelegenheiten, mit verschiedenen Kunden an diversen Projekten und in unterschiedlichen Teams zusammenzuarbeiten. Jedes Mal setzten wir uns für den höchstmöglichen Automatisierungsgrad ein und für die Annäherung an die kontinuierliche Integration. Oft rettete dies Projekte vor schwerwiegenden Konsequenzen.

Bevor ich zu den Vorteilen der Automatisierung komme, gebe ich Ihnen einen kurzen Überblick darüber, wie sie funktioniert.

Automatisierung der Softwareentwicklung

Der automatisierte Softwareentwicklungs-Prozess ist durch folgende Merkmale gekennzeichnet:

1. Ein einziges gemeinsames Code-Repository wird eingerichtet. Alle Entwickler legen den von ihnen geschriebenen Code im Repository ab. Derzeit ist Git das beliebteste Versionskontrollsystem. Der Code im Repository ist die einzige Quelle der Software im Projekt. Es werden keine zusätzlichen Skripte, Programme oder anderer Code per E-Mail verschickt oder auf andere Weise im Unternehmen verteilt.
2. Der sogenannte „Build-Prozess“ ist eingerichtet. Der Build-Prozess ist eine standardisierte Methode zur Erstellung und zum Bau nachfolgender Softwarekopien. Jeder Entwickler, Tester, jedes Testszenario und jede Mechanik verwendet den exakt gleichen Prozess, um die aktuelle Version der Software zu erhalten.
3. Der Build-Prozess ist automatisiert. Um die aktuelle Version der Software zu erhalten, sind keine umfangreichen manuellen Aktionen erforderlich. Im Idealfall ist der Build-Prozess ein weiteres Skript oder ein Stück Software, das ebenfalls im Code-Repository versioniert wird. Ein Entwickler lädt den neuesten Code aus dem Repository herunter, startet den Build-Prozess (z. B. durch Starten eines Skripts) und erhält den aktuellen Zustand der Anwendung. Dasselbe Skript sollte von allen Testtools und Testumgebungen sowie zum Erstellen von Demo-Versionen verwendet werden.
4. Der Build-Prozess ist schnell. Der Softwarepaketbau dauert nicht zu lange. Dies ermöglicht es, Testergebnisse und Korrekturen mehrfach zu implementieren.
5. Das Team commitet häufig Änderungen, bestenfalls täglich oder mehrmals täglich. Der Arbeitscode wird kontinuierlich in den Master-Zweig im Versionskontrollsystem gepusht.
6. Die Testumgebung sollte der Produktionsumgebung so ähnlich wie möglich sein. Im Idealfall wäre es eine direkte Kopie der Produktionsumgebung.
7. Der Prozess des Pushens der Software zur Produktion ist automatisiert. Im besten Fall sollte das Pushen neuer Änderungen zur Produktion durch einen einzigen Klick auf einen Button oder das Ausführen eines einzigen Skripts erfolgen.

Durch das Erreichen aller oben aufgelisteten Ziele gewinnen Sie viele Vorteile, die den Softwareentwicklungs-Prozess geordneter machen.

1. Sie können Entwicklungsumgebungen schnell neu erstellen. Eines der größten Probleme bei Projekten mit schlechter Automatisierung sind die ständigen Diskrepanzen zwischen der Funktionsweise der Software in der Produktion im Vergleich zu Entwicklungs- und Testumgebungen. Da die Änderungen zwischen Umgebungen von Hand repliziert werden müssen, wird dies entweder selten oder gar nicht getan. Jede einzelne Umgebung hat spezifische Eigenheiten, und wenn es viele davon gibt, wird dieses Problem nur noch verschärft. Somit steigt das Risiko, dass der in einer Umgebung erstellte Code oder eine Konfiguration in einer anderen Umgebung anders funktioniert. Automatisierte schnelle Umgebungs-Neuerstellungen beseitigen dieses Problem vollständig.
2. Es gibt nur eine Informationsquelle über den aktuellen Stand des Projekts: Der Build. Der Softwarebau gibt Ihnen ein echtes Bild davon, wie der Code aussieht und funktioniert. Die Bewertung der Ergebnisse ist klar, und es gibt keine Probleme wie „Es hat auf meinem Computer funktioniert“ oder „Es funktioniert in der Entwicklung, aber nicht im Test.“ Ein frischer und automatisierter Build eines Projekts ist das Einzige, das einer Bewertung unterzogen wird.
3. Sie können Software „bauen“ und deren Bereitstellung im Testumfeld testen, bis Sie den gewünschten Effekt und die Garantie erhalten, dass die Bereitstellung genau wie vorhergesagt abläuft und vorhersehbare Ergebnisse liefert.

Mit anderen Worten, die Vorteile der Build-Automatisierung lassen sich wie folgt zusammenfassen:

1. „Sie wissen, wo Sie stehen“ – Sie können in gewissem Maße Gewissheit über den aktuellen Zustand Ihrer Software haben.
2. Jeder arbeitet an der gleichen Version.
3. Es gibt eine einzige und objektive Möglichkeit, zu überprüfen, ob etwas funktioniert oder nicht.

Dies allein kann Ihnen das Schicksal vieler Teams ersparen, die viel Zeit damit verschwenden,

1. herauszufinden, warum etwas in einer Umgebung funktioniert hat, nur um in einer anderen zu scheitern,
2. oder zu versuchen, Fehler aus der Testumgebung in einer Entwicklungs- oder lokalen Umgebung zu replizieren.

Automatisierter Bau ist jedoch nur die halbe Miete. Tests sind die andere Hälfte. 

Automatisierte Tests

Die heutige Software ist sehr komplex und umfasst oft Hunderttausende von Codezeilen, die sich über viele Dateien erstrecken. Solche komplexen Projekte nutzen zahlreiche Bibliotheken und andere Abhängigkeiten. Änderungen im Code und in Bibliotheken neigen dazu, mehrere Funktionalitäten im System zu beeinflussen.

Beim Implementieren von Änderungen überprüfen Softwareentwickler normalerweise, ob der Code wie beabsichtigt funktioniert. Häufig haben sie jedoch nicht das Wissen über das System oder die Fähigkeit bzw. die Zeit, um zu überprüfen, ob ihre Änderungen andere Funktionalitäten des Systems, an dem sie arbeiten, beeinflussen.

Dasselbe gilt auch für Tester – sie sind einfach nicht in der Lage, das gesamte System auf Fehler zu überprüfen, die sich bei der Prüfung neuer Funktionalitäten eingeschlichen haben könnten. Wenn bei einem Projekt alle Testszenarien tatsächlich manuell mit jedem Deployment ausgeführt werden, beginnen Deployments mühsam und teuer zu werden. Jeder gefundene und anschließend behobene Fehler erfordert Änderungen im Codebestand, was bedeutet, dass das gesamte System von Grund auf neu getestet werden muss, oder es besteht das Risiko von Fehlern. Häufig führt die Verwendung solcher Praktiken zu einer langen Spirale von Tests, Fehlern, weiteren Tests, weiteren neuen Fehlern... Oder, um die Sache noch zu verschlimmern, schlampigen Tests, die dazu führen, dass Fehler in die Produktion gelangen.

Dieses Problem kann durch die Implementierung von automatisierten Tests gelöst werden. Es gibt viele Methoden zur Erstellung von Tests und Softwaretests, weshalb ich sie hier nicht auflisten werde, sondern nur die erforderlichen Merkmale beschreibe:

1. Tests sollten automatisiert sein und einfach durchzuführen sein. Jeder Entwickler sollte in der Lage sein, alle Tests in seiner Entwicklungsumgebung durchzuführen.
2. Tests sollten schnell sein, da sie sonst aufgrund ihrer langen Ausführungszeit möglicherweise übersprungen werden. Tests sollten jedes Mal durchgeführt werden, wenn die Software geändert wird. Im Idealfall sollte jeder Commit getestet werden, aber Sie sollten auf jeden Fall mindestens jeden Code testen, der in den Master-Zweig gepusht werden soll.
3. Tests sollten den größtmöglichen Umfang der Software abdecken. Die Anzahl der Tests und die Art ihrer Planung sollten es ermöglichen, alle wesentlichen und signifikanten Funktionen der Software zu testen, und das Team sollte sicher sein, dass die Tatsache, dass alle Tests erfolgreich abgeschlossen wurden, bedeutet, dass die Software ordnungsgemäß funktioniert. Es gibt viele Techniken zur Schätzung der Testabdeckung, die verwendet werden können, um die Anzahl der Tests zu überwachen.
4. Tests sollten Teil des Builds sein. Im Idealfall sollte jeder Build automatisch alle Tests durchführen und deren Ergebnisse anzeigen.
5. Jede Änderung sollte durch Testen des gesamten Systems überprüft werden. Nochmals, im Idealfall würden Sie jeden einzelnen Commit testen, aber oft reicht es aus, den Code zu testen, bevor er mit dem Master-Zweig zusammengeführt wird. Wenn ein Entwickler den Master-Zweig mit Code aktualisiert, der die Software beschädigt, behindert er die Arbeit anderer, die eine neue Aufgabe mit dem neuesten Build beginnen möchten – es wird einfach nicht funktionieren aufgrund von Fehlern im Code. Teams, die keine automatisierten Tests verwenden, stehen oft vor dem Problem, dass einige neue Commits einen Teil der Software beschädigen und alle, die daran arbeiten wollten, bis zur Behebung des Fehlers festgehalten sind. Automatisierte Tests verhindern solche Situationen.

Automatisierte Builds und Tests sind der Schlüssel zum Erfolg

Wenn Sie den Bauprozess zusammen mit dem Testen automatisieren, erhalten Sie einen Mechanismus, bei dem Sie immer den Zustand Ihrer Software kennen. Wichtig ist, dass Sie, bevor Sie neue Änderungen hinzufügen, überprüfen können, ob sie neue Fehler einführen. Dank dessen können Sie fast immer entscheiden, die aktuelle Version der Software in die Produktion zu bringen. Was noch wichtiger ist, Sie können dies schnell und sicher tun, weil es durch einen automatisierten Prozess erfolgt, der zuvor in einer Testumgebung getestet wurde, die identisch mit der Produktion ist.

Durch das Erreichen dieses Automatisierungsgrades können Sie sicher neue Funktionalitäten entwickeln, in der Gewissheit, dass sie sicher funktionieren und nichts kaputt machen, und dann Ihre Software bereitstellen. Im Grunde eliminieren Sie das Risiko, etwas kaputt zu machen, und falls Sie einen Fehler finden, können Sie ihn schnell beheben.

Unsere Erfahrung

Bei Droptica machen wir hauptsächlich Drupal-Entwicklung und Drupal-Support und versuchen, diese Methodiken auf jedes Projekt anzuwenden, das wir übernehmen oder von Grund auf neu starten.

In der Regel zahlen sich die investierte Zeit und Arbeit in die Erstellung von Tests sehr schnell aus. Die Anzahl der vor der Bereitstellung erforderlichen manuellen Tests fällt drastisch, was die Kosten ausgleicht. Automatisierte Tests ermöglichen es uns, alle Fehler und Irrtümer viel schneller zu erkennen. Oft bemerkten wir, dass wir, wenn wir mit der Erstellung automatisierter Tests für ein Projekt beginnen, das sie noch nie verwendet hat, viele Fehler finden, die vorher von niemandem bemerkt wurden.

Dank dessen hört das Team auf, nach Fehlern zu suchen, und verbringt mehr Zeit mit der Entwicklung von Software. Automatisierung übersetzt sich direkt in eine höhere Zufriedenheit und das Vertrauen unserer Kunden sowie in verkürzte Bearbeitungszeiten, mit einem zusätzlichen Vorteil – unser Team ist zufriedener mit seiner Arbeit.

Wenn die Automatisierung ordnungsgemäß implementiert ist und die Tests gut gestaltet sind, können wir unsere Software sogar mehrmals am Tag oder nach einem festgelegten Zeitplan – zum Beispiel einmal pro Woche – bereitstellen, ohne das Risiko einzugehen, unsere Produktionsumgebung zu zerstören. Wichtig ist, dass die Bereitstellung nicht zu lange dauert.