gradle

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.

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 7. Juli den Vortrag von Hans Dockter The Future of Gradle – The Ultimate Build System. Einlaß ist um 18:00 Uhr. Der Vortrag beginnt um 18:30 Uhr. Vortrag: The Future of Gradle – The Ultimate Build System We are convinced that Gradle is already the best available enterprise build system. Yet we are far from done. We have finally the R&D bandwidth to deeply improve Gradle in the areas where it lacks.

We are currently using Cargo in combination with Gradle to implement consumer based tests for one of our projects. In order to do so, we created a Gradle script to deploy a service web app into a Tomcat container via Cargo and pass its URL to our consumer test suite. As long as we run the build script locally, everything works fine. But we noticed that it failed every once in a while when running on certain build agents in our TeamCity build pipeline.

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.