Die nächste Welle von CI/CD - Visuelles CI/CD-Prozessdesign und Automatisierung

Continuous Integration (CI) und Continuous Delivery (CD) sind eine Reihe von Best Practices, die es Entwicklungsteams ermöglichen sollen, Produktänderungen häufiger und mit weniger Fehlern zu erstellen, zu ändern, zu verbessern und zu liefern. Der gesamte Prozess wird gewöhnlich als CI/CD Pipeline bezeichnet.

Testen als Teil von Continuous Integration (CI) und Continuous Delivery (CD)

Einer der wichtigsten Bestandteile von CI/CD ist das Testen. Auch das Testen muss per Definition kontinuierlich erfolgen. Denken Sie daran, dass wir sicherstellen wollen, dass wir unseren Stakeholdern qualitativ hochwertige Anwendungen zur Verfügung stellen. Kontinuierliche Tests bestehen aus automatisierten Regressionen, funktionalen Tests, Unit-Tests und Leistungstests. Diese Tests müssen als Teil der CI/CD-Pipeline ausgeführt werden.

CI/CD-Werkzeuge wie Jenkins, CircleCI, AWS CodeBuild, Travis CI, Atlassian Bamboooder andere sind heute die Tools der Wahl für CI/CD. Sie alle ermöglichen es DevOps-Ingenieuren, automatisierte Tests einzubinden. Zusätzlich bieten Dienste wie SauceLabs die Durchführung von CI/CD in großem Umfang und mit SLAs auf Unternehmensebene. Und es gibt viele andere innovative Tools, die in Ihrem Testköcher sein sollten - Tools wie scriptworks.io für die Verwendung eines Low-Code-Ansatzes zur Erstellung Ihrer Selenium-Skripte.

Heute möchte ich jedoch darüber sprechen, wie Sie die CI/CD-Automatisierung auf die nächste Stufe heben können, indem Sie visuelles Prozessdesign in Ihren CI/CD-Toolkit-Mix aufnehmen. WARNUNG - Wie jede Technologie ist auch diese nicht für jeden und nicht für jede Situation geeignet. Für viele von Ihnen wird dies ein Overkill sein und Sie werden sich vielleicht den Kopf kratzen und denken: "Wozu brauche ich das? Sie brauchen es vielleicht nicht.

Welche Art von Projekten sollte Visual CI/CD verwenden?

Wer sollte also daran interessiert sein, visuelle CI/CD-Prozessautomatisierung zu seinem aktuellen CI/CD-Prozess hinzuzufügen? Hier sind einige der Merkmale, auf die Sie achten sollten, um herauszufinden, ob Ihr Softwareprojekt die visuelle Prozessautomatisierung als Integration/Erweiterung Ihrer CI/CD-Werkzeuge nutzen sollte:   

• Mehrmandantenfähigkeit - Sie betreiben eine mehrmandantenfähige SaaS-Anwendung
• Beteiligung von Stakeholdern - Sie haben Kunden oder Partner, die in den Prozess der Entwicklung und Überwachung der Codequalität und -bereitstellung einbezogen werden müssen.
• Anpassung - Ihre Anwendung erlaubt es den Kunden, die Anwendung anzupassen, und als Ergebnis werden Ihre funktionalen Selenium-Tests dazu neigen, zu wachsen und sich häufig zu ändern (meiner bescheidenen Meinung nach ist dies vielleicht der wichtigste Grund für die Verwendung eines visuellen CI/CD-Prozessdesigns).
• Manuelle Freigabeschritte - Für bestimmte Arten von Mieteraktualisierungen, für die Einhaltung von ISO- und gesetzlichen Vorschriften oder aufgrund von Bestimmungen in Kundenverträgen können manuelle Genehmigungsschritte erforderlich sein.
• Automatisierte Warnmeldungen und Rollback-Regeln - Stakeholder und Kunden benötigen möglicherweise rechtzeitige Warnmeldungen aufgrund von Sicherheitsprotokollen, die sie befolgen oder die ihre Kunden von ihnen verlangen
• Zusammenarbeit - CI/CD wird immer häufiger zu einer geschäftskritischen Funktion und nicht nur zu einer von Entwicklern geleiteten Initiative. Daher wollen auch nicht-technische Stakeholder den Prozess verstehen und müssen zusammenarbeiten.
• Komplexe Lieferketten - Für Software, die von verschiedenen Teams und unabhängigen Unternehmen entwickelt wird, sind mehr visuelle Audits erforderlich.
• Parallele Testdurchführung - In größeren Projekten müssen Selenium-Tests parallel ausgeführt werden, um die Tests schneller und effizienter durchführen zu können

Selenium Vereinfacht

Heute zeigen wir Ihnen anhand eines Live-Beispiels, wie Sie visuelle Prozessautomatisierung für Ihr CI/CD integrieren können. Wir haben einen robusten und vollständig automatisierten Prozess mit ProcessMaker, einer Prozessautomatisierungstechnologie der nächsten Generation, entwickelt. Sie werden sehen, dass dies ein enormes Maß an zusätzlicher Flexibilität, Transparenz und Effizienz für die typische Art und Weise bietet, wie QA und CloudOps zusammenarbeiten, um automatisierte Tests durchzuführen und CI/CD-Pipelines zu betreiben. Wie bereits erwähnt, richtet sich diese Lösung an Entwicklungsteams, die komplexere Test- und Release-Deployment-Szenarien bewältigen müssen.

In diesem Beispiel ist unser Prozess mit verschiedenen CI/CD-bezogenen AWS-Services (CodePipeline, CodeCommit, CodeDeploy und benutzerdefinierte Lambda-Funktionen), Github und Selenium integriert. In Ihrem Fall könnten Sie sich für die Verwendung anderer CI/CD-Tools wie die oben genannten entscheiden. Sie können sich das Übersichtsvideo zur ProcessMaker-gestützten automatisierten QA-Testsuite hier ansehen.

Was wir im Video sehen werden

In unserer Beispielanwendung haben wir eine visuelle CI/CD-Pipeline zum Testen einer mandantenfähigen Unternehmensanwendung erstellt. Dieses Beispiel wurde für ein großes ERP-Unternehmen entwickelt, das mit zahlreichen Lieferanten zusammenarbeiten musste. Außerdem konnte die Anwendung von den Kunden angepasst werden, was bedeutete, dass bei jedem Upgrade nicht nur die Basisanwendung getestet werden musste, sondern die Kunden auch in der Lage sein mussten, Selenium-Tests in ihren eigenen Git-Repositories zu speichern, um sie vor der Bereitstellung von Upgrades der Basissoftware zu testen. Darüber hinaus könnten einige Kunden öffentliche Clouds mit festen Zeitrahmen nutzen, während andere private Clouds nutzen, die eine manuelle Zustimmung des Kunden erfordern, nachdem er eine bestimmte Zeitspanne zur Überprüfung von Anomalien in seinen lokalen Testfällen erhalten hat.  

Wie Sie also sehen, gibt es in diesem Fall eine Reihe von Gründen, warum ein visueller Prozess die traditionelle Nutzung einer CI/CD-Suite erheblich verbessern kann.

Wie das Verfahren funktioniert

Dieser Prozess wird von einem Code-Commit in AWS CodeCommit gestartet. Dies löst die AWS CodePipeline einen Aufruf an die ProcessMaker-API aus, um den Prozess zu starten. ProcessMaker prüft dann die CodeCommit-Informationen, um zu wissen, welche funktionalen Selenium-Tests ausgeführt werden müssen, und ruft das entsprechende Github-Repository oder die entsprechenden Repositories auf, um die korrekte Version der auszuführenden Testsuites zu laden.

Die Selenium-Testsuiten werden dann parallel ausgeführt und von der ProcessMaker-Workflow-Engineverwaltet. Das Schöne dabei ist, dass ProcessMaker eine wirklich massive Parallelisierung von Tests in der Cloud bewältigen kann. Dies kann sowohl für die Orchestrierung als auch für die Ausführung sein, oder vielleicht nur für die Orchestrierung (wenn sie mit etwas wie der Sauce Labs API für die Ausführung und zusätzliches Reporting integriert ist).

Verwendung von Geschäftsregeln zur Auswertung von Testergebnissen vor der Übergabe an CodeDeploy

Die Testantworten werden an ProcessMaker zurückgegeben und in dem entsprechenden ProcessMaker-Objekt gespeichert. Dieses Objekt wird dann von ProcessMaker-Geschäftsregeln ausgewertet, um festzustellen, ob einer der Tests fehlgeschlagen ist. Wenn einige der Tests fehlgeschlagen sind, werden die entsprechenden Personen benachrichtigt, und der Test wird erneut ausgeführt. Wenn alle Tests erfolgreich waren, ruft ProcessMaker AWS auf, um den Code in die Produktion zu überführen.

Dieser Prozess ist ein vollautomatischer Prozess, der keine menschliche Interaktion erfordert. Da der Prozess jedoch visuell gestaltet und nicht fest kodiert ist, kann er leicht und visuell geändert werden. Auf diese Weise können alle interessierten Parteien den Prozess sehen und überprüfen. Wenn also, wie bereits erwähnt, ein bestimmter Kunde einen Genehmigungsschritt (oder mehrere Schritte) benötigt, bevor er zur Code-Implementierungsphase übergehen kann, können wir dies auf der Grundlage einer einfachen Geschäftsregel problemlos durchführen. Andere müssen möglicherweise auf verschiedene Github- (oder andere) Repositories zurückgreifen, die sowohl öffentlich als auch privat sind und von verschiedenen Parteien gepflegt werden.

Ausführen von Tests in einem benutzerdefinierten Docker-Image

Die Tests, die in diesem Beispiel von GitHub abgerufen werden, werden in Python geschrieben, wobei Script-Tasks und ein benutzerdefiniertes Docker-Image in ProcessMaker verwendet werden, um Selenium-Tests gegen diese Zielumgebung auszuführen. ProcessMaker ermöglicht es QA-Teams, Skripte in jeder beliebigen Programmiersprache zu entwickeln, um Selenium-Tests aufzurufen und sie in unabhängigen Docker-Containern auszuführen. Diese Docker-Container können sogar die Sprache sowie zusätzliche Bibliotheken oder SDKs nach Bedarf laden.

Warum sogar Entwickler Low Code lieben

Obwohl CI/CD von Entwicklern für Entwickler erfunden wurde, geht seine Bedeutung schnell über das Backoffice hinaus. Daher müssen immer mehr Beteiligte verstehen, was hier geschieht. Das bedeutet, dass sich Haftung, Entschädigung, Zertifizierung und vieles mehr auf die Verantwortung auswirken, mit der CI/CD betrieben wird. Daher ist es eine natürliche Entwicklung von CI/CD, dass ein gewisses Maß an visuellem Low-Code/No-Code-Tooling jetzt erforderlich ist. Solange der visuell orchestrierte No-Code-Workflow es den Entwicklern ermöglicht, ihre bevorzugten Tools (Docker, Kubernetes, Selenium, Git usw.) zu verwenden, haben wir festgestellt, dass die Entwickler diese zusätzlichen Tools lieben.

Wenn Sie mehr über den Einsatz von visuellem CI/CD zur Erweiterung Ihres aktuellen Prozesses erfahren möchten, wenden Sie sich bitte an ProcessMaker oder sehen Sie sich dieses Video an.