Tobias Gesellchen

Nach der Migration von Ghost nach Hugo/Netlify werden Artikel in GitHub erstellt und bearbeitet. Bitte folge der Anleitung in /authoring!

We want to enable everyone contributing articles to the Europace Blog. Here you can learn how to create and edit articles.

We’re a big fan of everything related to continuous deployment. There’s one aspect to tackle when continuously delivering new releases to our clients: we don’t want their connections to break during a deployment, because they might just be in the process of editing a form - with their customers sitting right beside them. Instead of the increased risk to have an unavailable backend, we want our clients to not even notice any change.

This is the final part of the article series about our continuous deployment pipeline. The previous articles showed you how we build and publish our Spring Boot based application, perform AngularJS end-to-end tests with Protractor, and how we perform contract tests to external services as consumer and provider as well. What’s missing are the description of how we package our application in Docker images, and how we distribute and deploy them to our production servers.

In part four of our series about our continuous deployment pipeline you’ll learn about how we perform contract tests to ensure our service stays compatible with other service producers and our consumers as well. Please read the introductury post to learn about the other articles and the overall context of our deployment pipeline. This article contains both an introduction to contract testing, and our individual implementation of contract testers. If you’re new to the contract testing concept, just read on.

This is the third part in our series about our deployment of a JVM and AngularJS based application using Gradle as build tool and Docker as deployment vehicle. You’ll find the overview on all posts in the introductury post. As seen in the overview, our next step in the deployment pipeline performs so called e2e tests. The common Gradle project setup has already been described in part 2, so we can start with the Gradle script for the e2e test submodule.

After a quite long holiday break we now continue our series about the Continuous Deployment Pipeline with Gradle and Docker. This post is about the first step where our build chain creates the Spring Boot packages and publishes them to our Nexus repository manager. As shown in the high-level overview below, it is only a quite small part of the complete pipeline: Gradle and Spring Boot provide you a very convenient build and plugin system and work out of the box for standard builds.

This series of posts will show you some aspects of our continuous deployment pipeline for one of our products. It is built, tested and deployed to our servers by using Gradle, while the application itself runs inside Docker containers. We want to show you how we use Gradle to implement a complete pipeline with minimal dependency on command line tools. We’ll also describe how to perform rollouts to production without the need for shell scripts or even remote shell access, by using the Docker remote API.

Docker provides a lightweight virtual environment by using Linux containers (LXC). We are establishing Docker in one of our projects to implement continuous delivery. For host management we use Puppet, which itself relies on some facts provided by their tool Facter. Our Puppet modules make use of the ipaddress fact, determined by a built-in Facter script. We regard the ipaddress as the public IP address of the host. As described at gesellix.

As you might have noticed, AngularJS 1.2.2 1.2.3 has been released lately, without dedicated announcement. Our update from an AngularJS 1.2-rc2 has been quite smooth, only two hints might be noteable in addition to the official migration guide. With the current version the AngularJS team has fixed some issues regarding the isolate scope as described in the changelog for the 1.2.0 release or at the relevant GitHub issues #1924 and #2500.

AngularJS helps with loading your app through dependency injection based on ordered class instantiation. Nevertheless, you sometimes need to know whether any pending request or function call has been finished in order to initialize your controllers, $scope or services. This article describes our solution to split the application lifecycle into several phases, namely „instantiation“, „initialization“ and „running“. You can find the downloadable code at GitHub, a working demo is available at jsfiddle.

You probably know about using Annotation Types for your custom Gradle plugin input values: class MyTask extends DefaultTask { @Input String aSimpleProperty @InputFile File anInputFile @Input @Optional String[] optionalProperty @OutputFile File anOutputFile @TaskAction def performTask() { // … } } Using complex task input When using a more complex input model, you can try something like this: class TaskConfiguration { String aSimpleProperty File anInputFile String[] optionalProperty } class MyTask extends DefaultTask { @Input TaskConfiguration myConfiguration @OutputFile File anOutputFile @TaskAction def performTask() { // … } } After running that task Gradle will try to serialize your TaskConfiguration, but will fail due to the missing Serializable interface declaration.

Im Rahmen der Entwicklung eines unserer Frontends verwenden wir node.js. Node.js erlaubt Paketmanagement mit Hilfe des Node Package Managers (NPM), der ähnlich wie Maven eine global verfügbare Registry verwendet. Einrichten einer lokalen NPM-Registry Die NPM-Registry wird auf einem nicht immer stabil erreichbarem Host bereitgestellt. Um die Latenz beim Abruf der aktuellen Paketinformationen zu vermeiden und um Downtimes möglichst gut kompensieren zu können, kann man einen Mirror der NPM-Registry im lokalen Netz bereitstellen.

Im Rahmen von Unit-Tests möchte man die Anbindung externer Systeme vermeiden um Stabilität der Tests zu gewährleisten. Leider hat man genau dann Probleme, wenn man gerade diese Anbindung oder die Integration mit externen Systemen testen möchte. Für solche Unit-Test mit integrativem Charakter kann man Mocks verwenden, die recht spezifisch für den jeweiligen Anwendungsfall selbst implementiert werden. Wenn es allerdings an die Implementierung eines Mail-Server Mocks geht, ist der Aufwand der Eigenimplementierung oft nicht mehr gerechtfertigt.

Hier wird das Erstellen eines lokalen Keystores mit self signed certificate für einen Tomcat und Java-Clients beschrieben. Die Inhalte sind größtenteils aus einer externen Quelle übernommen und darüber hinaus durch weitere Details ergänzt. Im Rahmen dieses Artikels werden diverse Dateien erzeugt, die für die Erzeugung eines Java-Keystores mit selbst-signierten Zertifikaten verwendet werden. Mit einem durch eine offizielle Certificate Authority (CA) signierten Zertifikat sind einige Schritte nicht notwendig. Erstellen des lokalen Keystores für den Tomcat