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.
On Wednesday Feb 11, the evening before microxchg – the micro services conference, Hypoport is hosting the microservices meetup Berlin with talks from two of the conference speakers. Richard Roger will talk about Seneca Node JS μServices Framework Peter Rossbach will talk about Docker Orchestration Please register on microservices meetup Berlin. See you there, Leif
Docker Berlin is back! You can now follow us on Twitter too @DockerBerlin To init and containerize this new year properly we have two great speakers lined-up at Hypoport on Jan, 19th. Johannes Ziemke [Docker Inc.] and Sascha Möllering [ZANOX.de AG] Managing containers with Docker…and why you’ll love it – Johannes Ziemke What are the challenges of today’s infrastructures, why containers are the right building blocks and Docker the right tool to manage those.
We are proud to announce that we are part of the Docker Global Hack Day #2. Join other members of the Docker community to hack on Docker projects using the next big Docker release! You’re all invited to Hypoport HQ in Berlin for a hacking session while sharing a meal/drink with fellow Dockers. This hackathon is your last chance to win a ticket to the sold out DockerCon Europe. Please register using our meetup event page.
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.