Before we go into details of the flow let’s take a look at the following example.

When having only a handful of applications, performing end to end testing is beneficial. From the operations perspective it’s maintainable for a finite number of deployed instances. From the developers perspective it’s nice to verify the whole flow in the system for a feature.

In case of microservices the scale starts to be a problem:

The questions arise:

• Should I queue deployments of microservices on one testing environment or should I have an environment per microservice?

  • If I queue deployments people will have to wait for hours to have their tests ran - that can be a problem

• To remove that issue I can have an environment per microservice

  • Who will pay the bills (imagine 100 microservices - each having each own environment).

  • Who will support each of those environments?

  • Should we spawn a new environment each time we execute a new pipeline and then wrap it up or should we have them up and running for the whole day?

• In which versions should I deploy the dependent microservices - development or production versions?

  • If I have development versions then I can test my application against a feature that is not yet on production. That can lead to exceptions on production

  • If I test against production versions then I’ll never be able to test against a feature under development anytime before deployment to production.

One of the possibilities of tackling these problems is to…​ not do end to end tests.

If we stub out all the dependencies of our application then most of the problems presented above disappear. There is no need to start and setup infrastructure required by the dependant microservices. That way the testing setup looks like this:

Such an approach to testing and deployment gives the following benefits (thanks to the usage of Spring Cloud Contract):

• No need to deploy dependant services

• The stubs used for the tests ran on a deployed microservice are the same as those used during integration tests

• Those stubs have been tested against the application that produces them (check Spring Cloud Contract for more information)

• We don’t have many slow tests running on a deployed application - thus the pipeline gets executed much faster

• We don’t have to queue deployments - we’re testing in isolation thus pipelines don’t interfere with each other

• We don’t have to spawn virtual machines each time for deployment purposes

It brings however the following challenges:

• No end to end tests before production - you don’t have the full certainty that a feature is working

• First time the applications will talk in a real way will be on production

Like every solution it has its benefits and drawbacks. The opinionated pipeline allows you to configure whether you want to follow this flow or not.

The general view behind this deployment pipeline is to:

• test the application in isolation

• test the backwards compatibility of the application in order to roll it back if necessary

• allow testing of the packaged app in a deployed environment

• allow user acceptance tests / performance tests in a deployed environment

• allow deployment to production

Obviously the pipeline could have been split to more steps but it seems that all of the aforementioned actions comprise nicely in our opinionated proposal.

For the demo purposes we’re providing Docker Compose setup with Artifactory and Concourse / Jenkins tools. Regardless of the picked CD application for the pipeline to pass one needs a Cloud Foundry instance (for example Pivotal Web Services or PCF Dev) and the infrastructure applications deployed to the JAR hosting application (for the demo we’re providing Artifactory). The infrastructure applications are Eureka for Service Discovery and Stub Runner Boot for running Spring Cloud Contract stubs.

There are 4 apps that are composing the pipeline

• Github Webhook

• Github Analytics

• Github Eureka

• Github Stub Runner Boot

You need to fork only these. That’s because only then will your user be able to tag and push the tag to repo.

• Github Webhook

• Github Analytics

Concourse + Artifactory can be run locally. To do that just execute the start.sh script from this repo.

The setup_docker_compose.sh script should be executed once only to allow generation of keys.

The 192.168.99.100 param is an example of an external URL of Concourse (equal to Docker-Machine ip in this example).

Then Concourse will be running on port 8080 and Artifactory 8081.

TIP: You can skip this step if you have CF installed and don’t want to use PCF Dev The only thing you have to do is to set up spaces.

You have to download and start PCF Dev. A link how to do it is available here.

The default credentials when using PCF Dev are:

You can start the PCF dev like this:

You’ll have to create 3 separate spaces (email admin, pass admin)

You can also execute the ./tools/pcfdev-helper.sh setup-spaces to do this.

If you go to Concourse website you should see sth like this:

You can click one of the icons (depending on your OS) to download fly, which is the Concourse CLI. Once you’ve downloaded that (and maybe added to your PATH) you can run:

If fly is properly installed then it should print out the version.

The repo comes with credentials-sample.yml which is set up with sample data (most credentials) are set to be applicable for PCF Dev. Copy this file to a new file credentials.yml (the file is added to .gitignore so don’t worry that you’ll push it with your passwords) and edit it as you wish. For our demo jus setup:

• app-url - url pointing to your forked github-webhook repo

• github-private-key - your private key to clone / tag GitHub repos

• repo-with-jars - the IP is set to the defaults for Docker Machine. You should update it to point to your setup

If you don’t have a Docker Machine just execute ./whats_my_ip.sh script to get an external IP that you can pass to your repo-with-jars instead of the default Docker Machine IP.

Below you can see what environment variables are required by the scripts. To the right hand side you can see the default values for PCF Dev that we set in the credentials-sample.yml.

Log in (e.g. for Concourse running at 192.168.99.100 - if you don’t provide any value then localhost is assumed). If you execute this script (it assumes that either fly is on your PATH or it’s in the same folder as the script is):

Next run the command to create the pipeline.

Then you’ll create a github-webhook pipeline under the docker alias, using the provided credentials.yml file. You can override these values in exactly that order (e.g. ./set-pipeline.sh some-project another-target some-other-credentials.yml)

Sure! Just change the app-url in credentials.yml!

Not really. This is an opinionated pipeline that’s why we took some opinionated decisions like:

• usage of Spring Cloud, Spring Cloud Contract Stub Runner and Spring Cloud Eureka

• application deployment to Cloud Foundry

• For Maven:

  • usage of Maven Wrapper

  • artifacts deployment by ./mvnw clean deploy

  • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded

  • running smoke tests on a deployed app via the smoke Maven profile

  • running end to end tests on a deployed app via the e2e Maven profile

• For Gradle (in the github-analytics application check the gradle/pipeline.gradle file):

  • usage of Gradlew Wrapper

  • deploy task for artifacts deployment

  • running smoke tests on a deployed app via the smoke task

  • running end to end tests on a deployed app via the e2e task

  • groupId task to retrieve group id

  • artifactId task to retrieve artifact id

  • currentVersion task to retrieve the current version

  • stubIds task to retrieve list of collaborators for which stubs should be downloaded

This is the initial approach that can be easily changed in the future.

Sure! It’s open-source! The important thing is that the core part of the logic is written in Bash scripts. That way, in the majority of cases, you could change only the bash scripts without changing the whole pipeline. You can check out the scripts here.

When deploying the app to stage or prod you can get an exception Insufficient resources. The way to solve it is to kill some apps from test / stage env. To achieve that just call

You can also execute ./tools/pcfdev-helper.sh kill-all-apps that will remove all demo-related apps deployed to PCF dev.

You must have pushed some tags and have removed the Artifactory volume that contained them. To fix this, just remove the tags

Yes! Assuming that pieline name is github-webhook and job name is build-and-upload you can running

Don’t worry…​ most likely you’ve just forgotten to click the play button to unpause the pipeline. Click to the top left, expand the list of pipelines and click the play button next to github-webhook.

Another problem that might occur is that you need to have the version branch. Concourse will wait for the version branch to appear in your repo. So in order for the pipeline to start ensure that when doing some git operations you haven’t forgotten to create / copy the version branch too.

If you play around with Jenkins / Concourse you might end up with the routes occupied

Just delete the routes

You can also execute the ./tools/pcfdev-helper.sh delete-routes

Most likely you’ve forgotten to update your local settings.xml with the Artifactory’s setup. Check out this section of the docs and update your settings.xml.

There are 4 apps that are composing the pipeline

• Github Webhook

• Github Analytics

• Github Eureka

• Github Stub Runner Boot

You need to fork only these. That’s because only then will your user be able to tag and push the tag to repo.

• Github Webhook

• Github Analytics

Jenkins + Artifactory can be ran locally. To do that just execute the start.sh script from this repo.

Then Jenkins will be running on port 8080 and Artifactory 8081. The provided parameters will be passed as env variables to Jenkins VM and credentials will be set in your set. That way you don’t have to do any manual work on the Jenkins side. In the above parameters, the third parameter could be yourForkedGithubOrg or yourGithubUsername. Also the REPOS env variable will contain your GitHub org in which you have the forked repos.

You have to download and start PCF Dev. A link how to do it is available here.

The default credentials when using PCF Dev are:

You can start the PCF dev like this:

You’ll have to create 3 separate spaces (email admin, pass admin)

You can also execute the ./tools/pcfdev-helper.sh setup-spaces to do this.

We already create the seed job for you but you’ll have to run it. When you do run it you have to provide some properties. By default we create a seed that has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and `github-analytics'.

We already create the seed job for you but you’ll have to run it. When you do run it you have to provide some properties. By default we create a seed that has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and github-analytics.

It’s enough to set the ARTIFACTORY_URL environmental variable before executing tools/deploy-infra.sh. Example for deploying to Artifactory at IP 192.168.99.100

So that ./mvnw deploy works with Artifactory from Docker we’re already copying the missing settings.xml file for you. It looks like this:

If you want to use your own version of Artifactory / Nexus you have to update the file (it’s in seed/settings.xml).

If you want to only play around with the demo that we’ve prepared you have to set ONE variable which is the REPOS variable. That variable needs to consists of comma separated list of URLs to repositories containing business apps. So you should pass your forked repos URLs.

You can do it in the following ways:

• globally via Jenkins global env vars (then when you run the seed that variable will be taken into consideration and proper pipelines will get built)

• modify the seed job parameters (you’ll have to modify the seed job configuration and change the REPOS property)

• provide the repos parameter when running the seed job

For the sake of simplicity let’s go with the last option.

Since our pipeline is setting the git user / name explicitly for the build step you’d have to go to Configure of the build step and modify the Git name / email. If you want to set it globally you’ll have to remove the section from the build step and follow these steps to set it globally.

You can set Git email / user globally like this:

In your scripts we reference the credentials via IDs. These are the defaults for credentials

If you already have in your system a credential to for example tag a repo you can use it by passing the value of the property GIT_CREDENTIAL_ID

With scripted that but if you needed to this manually then this is how to do it:

You can check the Jenkins logs and you’ll see

To fix it you have to do exactly what the warning suggests…​ Also ensure that the Groovy token macro processing checkbox is set.

You can see that the Jenkins version is properly set but in the build version is still snapshot and the echo "${PIPELINE_VERSION}" doesn’t print anything.

You can check the Jenkins logs and you’ll see

To fix it you have to do exactly what the warning suggests…​

Docker compose, docker compose, docker compose…​ The problem is that for some reason, only in Docker, the execution of Java hangs. But it hangs randomly and only the first time you try to execute the pipeline.

The solution to this is to run the pipeline again. If once it suddenly, magically passes then it will pass for any subsequent build.

Another thing that you can try is to run it with plain Docker. Maybe that will help.

Sure! you can pass REPOS variable with comma separated list of project_name$project_url format. If you don’t provide the PROJECT_NAME the repo name will be extracted and used as the name of the project.

E.g. for REPOS equal to:

https://github.com/spring-cloud-samples/github-analytics,https://github.com/spring-cloud-samples/github-webhook

will result in the creation of pipelines with root names github-analytics and github-webhook.

E.g. for REPOS equal to:

foo$https://github.com/spring-cloud-samples/github-analytics,bar$https://github.com/spring-cloud-samples/atom-feed

will result in the creation of pipelines with root names foo for github-analytics and bar for github-webhook.

Not really. This is an opinionated pipeline that’s why we took some opinionated decisions like:

• usage of Spring Cloud, Spring Cloud Contract Stub Runner and Spring Cloud Eureka

• application deployment to Cloud Foundry

• For Maven:

  • usage of Maven Wrapper

  • artifacts deployment by ./mvnw clean deploy

  • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded

  • running smoke tests on a deployed app via the smoke Maven profile

  • running end to end tests on a deployed app via the e2e Maven profile

• For Gradle (in the github-analytics application check the gradle/pipeline.gradle file):

  • usage of Gradlew Wrapper

  • deploy task for artifacts deployment

  • running smoke tests on a deployed app via the smoke task

  • running end to end tests on a deployed app via the e2e task

  • groupId task to retrieve group id

  • artifactId task to retrieve artifact id

  • currentVersion task to retrieve the current version

  • stubIds task to retrieve list of collaborators for which stubs should be downloaded

This is the initial approach that can be easily changed in the future.

Sure! It’s open-source! The important thing is that the core part of the logic is written in Bash scripts. That way, in the majority of cases, you could change only the bash scripts without changing the whole pipeline.

[jenkins_resources]] When deploying the app to stage or prod you can get an exception Insufficient resources. The way to solve it is to kill some apps from test / stage env. To achieve that just call

You can also execute ./tools/pcfdev-helper.sh kill-all-apps that will remove all demo-related apps deployed to PCF dev.

You must have pushed some tags and have removed the Artifactory volume that contained them. To fix this, just remove the tags

• by default we assume that you have jdk with id jdk8 configured

• if you want a different one just override JDK_VERSION env var and point to the proper one

To change the default one just follow these steps:

And that’s it!

When you get sth like this:

most likely you’ve passed a wrong password. Check the credentials section on how to update your credentials.

If you receive a similar exception:

It means that you’ve forgotten to create the spaces in your PCF Dev installation.

If you play around with Jenkins / Concourse you might end up with the routes occupied

Just delete the routes

You can also execute the ./tools/pcfdev-helper.sh delete-routes

Most likely you’ve forgotten to update your local settings.xml with the Artifactory’s setup. Check out this section of the docs and update your settings.xml.