Fail Fast mit dem Staging Properties Maven Plugin

Für Mule-Applikationen gilt das gleiche wie für Webanwendungen. Sie durchlaufen in der Regel mehrere Deployment Stages bis sie auf dem Produktivsystem angelangt sind.
Etabliert haben sich dabei Stages wie zum Beispiel Dev, Test, Pre-Prod und Prod. Manchmal werden noch zusätzliche Umgebungen eingeführt, um das Risiko eines Fehlers auf dem Produktivsystem noch weiter zu minimieren.

Das Artefakt wird bei einem solchen Stage Durchlauf ein einziges mal vorab erstellt und beginnend mit der Dev-Umgebung auf allen Stages nacheinander deployed. Ein Artefakt wird allerdings erst eine Stage weitergereicht, wenn es das Deployment inklusive Tests auf der Umgebung bestanden hat. Im Falle von fehlgeschlagenen Tests oder Deployments, wird das Artefakt nicht auf die nächste Stufe gebracht.

Von Stage zu Stage wird die Umgebung immer ähnlicher zum Produktivsystem. Während auf der Dev-Umgebung beispielsweise noch mit Mocks und In-Memory-Datenbanken gearbeitet werden könnte, führen auf der Test Stage bereits Fremdsysteme Tests gegen die Applikation aus.

Properties-Dateien

Da sich die Einflussgrößen, wie zum Beispiel Fremdsysteme anstelle von Mocks zu verwenden, von Stage zu Stage unterscheiden, ändern sich dadurch auch Konfigurationen wie die URLs und Ports zu den Systemen. Während auf der Entwicklerumgebung noch auf dem localhost gearbeitet wird, werden auf der Test Umgebung andere Testsysteme eingebunden. Andere umgebungsabhängige Einstellungen sind z.B. User und Passwörter zum Zugriff auf Datenbanken oder APIs.

Solche Konfigurationen lassen sich in Mule in Properties auslagern, sogenannte „Property Placeholder“ (https://docs.mulesoft.com/mule-user-guide/v/3.8/configuring-properties ), die Mule aus Spring übernommen hat. Diese Properties lassen sich wiederum in Files zusammenfassen, die üblicherweise die Endung „.properties“ haben. Für verschlüsselte Property-Files bietet Anypoint Enterprise Security zudem die Credentials Vault an, verschlüsselte Property-Files, die sich über einen speziellen Mechanismus laden lassen (https://docs.mulesoft.com/mule-user-guide/v/3.8/mule-credentials-vault ). Ein Pattern, um umgebungsabhängige Einstellungen zu verwalten ist, ein (oder mehrere) Property-Files je Umgebung zu definieren, die die Verbindungsinformationen zu anderen Systemen, Datenbanken, Message Brokers oder auch Security Einstellungen beinhalten. Hier ein Beispiel für eine Mule Applikation, die auf den vier Umgebungen Dev, Test, Pre-Prod und Prod deployed wird:

Das Artefakt bleibt wie bereits erwähnt auf allen Stages identisch, folglich bleibt auch die Anzahl der Einträge in den Properties identisch. Schließlich beinhaltet das Artefakt die gleiche Anzahl an Mule flows mit Verbindungen zu anderen Systemen.

Zur Entwicklungszeit muss somit also bereits an alle folgenden Stages gedacht und die Properties-Dateien mit Werten versehen werden. Dabei kann es schnell passieren, dass Einträge vergessen werden. In Mule existiert leider kein Mechanismus, der die Properties-Dateien prüft und auf fehlerhafte oder fehlende Einträge hinweist. So etwas fällt dann im schlimmsten Fall erst beim Deployment auf die jeweilige Stage auf. Je später es auffällt, desto teurer wird die Änderung. Besonders wenn die Deployments nicht mehr in der Hand der Entwickler liegen und Fremdsysteme ab einer bestimmten Stage auch noch (manuell) gegen die Applikation testen. Grundsätzlich gilt, je mehr Leute beteiligt oder betroffen sind, desto teurer wird es.

Maven Plugin to the rescue

Um das zu verhindern haben wir ein Maven Plugin entwickelt, das die Properties-Dateien schon zur Entwicklungszeit prüft und den Maven Build abbricht, sobald die Properties-Dateien nicht konsistent zueinander sind. Wir verwenden das Plugin derzeit für unsere Mule Projekte. Es kann aber z.B. auch in Spring Projekten verwendet werden. Das Konzept der properties gibt es dort auch.

Das Plugin befindet sich auf GitHub und steht unter der Apache-Lizenz. Derzeit steht es in der Version 1.0.2 in Maven Central für jeden zur Verfügung.

Um das Plugin zu verwenden, muss es als plugin unter build -> plugins zur pom.xml hinzugefügt werden.

<build>
  <plugins>
    ...
    <plugin>
      <groupId>de.codecentric</groupId>
      <artifactId>check-staging-properties-maven-plugin</artifactId>
      <version>1.0.2</version>
      <executions>
        <execution>
          <phase>verify</phase>
          <goals>
            <goal>check</goal>
          </goals>
        </execution>
      </executions>
      <configuration>
        <directory>src/main/resources</directory>
        <groups>
          <group>credentials-(.*).\.properties</group>
          <group>settings-(.*).\.properties</group>
      </groups>
      </configuration>
    </plugin>
    ...
  </plugins>
</build>

Danach ist das Plugin Bestandteil des Builds und prüft, ob die properties konsistent zueinander sind. Genauer gesagt prüft es, ob:

1. die Anzahl der keys in allen properties übereinstimmt.
2. die keys identisch sind
3. zu allen keys auch values vorhanden sind.

In dem gezeigten Beispiel ist das Plugin an die Verify-Phase gebunden. Theoretisch kann das Plugin auch an eine frühere Phase gebunden werden.
Jede Konfiguration ist mit einem Standardwert versehen. Sofern sich die properties in src/main/resources befinden, kann die explizite Angabe des directory also weggelassen werden.

Für die Angabe der groups gilt etwas anderes. Werden sie weggelassen, so werden alle Properties betrachtet und miteinander verglichen. Durch die Angabe von groups in Form von regulären Ausdrücken können Teilmengen gebildet werden, die von dem Plugin separat untersucht werden. Hilfreich ist das bei mehreren verschiedenen Properties. Properties, die mit credentials zu tun haben sollen beispielsweise nicht mit settings properties verglichen werden. Durch das grouping Feature wird das verhindert.

Fazit

Wir haben das Plugin selbst in mehreren unserer Mule-Projekte im Einsatz und können mit dem derzeitigen Feature Set alle unsere Anforderungen abdecken. Falls ihr allerdings Anregungen und Wünschen zu neuen oder bestehenden Features habt, würden wir uns sehr über einen Issue auf GitHub oder einen Kommentar unter diesem Blogpost freuen. Ansonsten wünschen wir viel Spaß mit dem Plugin! 🙂