A while ago there was a contest to develop a plugin for a Continuous Delivery system called Go.
I decided to "have a go," and my product was judged to be the best suited to the criteria of the competition.
When I was first contemplating producing something a colleague suggested that I do something with Docker because that was the hot technology at the time. Instead I opted for something that I believed would benefit my team in our use of Cloud Foundry.
Rather than going for the obvious - automating deployment to Cloud Foundry - I chose to give developers a system which could alert their CI pipeline when an app has been re-deployed.
Github doesn't seem to give statistics on downloads, so I find myself a little frustrated at not being able to tell how many people are actually making use of my first serious foray into open source software.
Showing posts with label Cloud Foundry. Show all posts
Showing posts with label Cloud Foundry. Show all posts
Thursday, 23 April 2015
Friday, 20 February 2015
Go CD Cloud Foundry plugin
In February 2015 I developed a Go CD server plugin to enable triggering of builds when a Cloud Foundry application has been deployed.
This post is intended as an introduction to how to use this plugin.
A starting assumption is that you already have the plugin installed on your Go CD server.
Update: Binary jars are available:
https://github.com/stephen-souness-springer/springer-gocd-cloudfoundry-plugin/releases
The source code is also available on Github:
https://github.com/stephen-souness-springer/springer-gocd-cloudfoundry-plugin
Step 1
Navigate to the Package Repositories section of the Admin menu
To make sure that you have supplied the correct credentials - and confirm that your Go server can connect to Cloud Foundry you can use the Check Connection button before choosing to save the configuration.
You're now ready to include some Cloud Foundry configuration to a build pipeline with your newly available repository.
Step 2
The Check Package button will trigger a check on two levels - first that the supplied credentials can log in, and second that an application exists which starts with the specified App Name.
Step 3
The next step in your pipeline definition depends on what you want to do when a change is detected. From the example settings above there will be an environment variable called GO_PACKAGE_MYCLOUDFOUNDRYDEV_SERVICEX_LABEL set with the latest matching detected app version.
This post is intended as an introduction to how to use this plugin.
A starting assumption is that you already have the plugin installed on your Go CD server.
Update: Binary jars are available:
https://github.com/stephen-souness-springer/springer-gocd-cloudfoundry-plugin/releases
The source code is also available on Github:
https://github.com/stephen-souness-springer/springer-gocd-cloudfoundry-plugin
Step 1
Navigate to the Package Repositories section of the Admin menu
Add a new repository with your CloudFoundry API credentials.
Update: In version 1.0.1 the password property has changed to be secured - so you won't see it in cleartext the way is is shown here.
You're now ready to include some Cloud Foundry configuration to a build pipeline with your newly available repository.
Step 2
The Check Package button will trigger a check on two levels - first that the supplied credentials can log in, and second that an application exists which starts with the specified App Name.
Step 3
The next step in your pipeline definition depends on what you want to do when a change is detected. From the example settings above there will be an environment variable called GO_PACKAGE_MYCLOUDFOUNDRYDEV_SERVICEX_LABEL set with the latest matching detected app version.
Tuesday, 17 June 2014
Quick fixes - the road to pain
After adding some new dependencies to our application we discovered that the Cloud Foundry deploy would no longer work. The error related to duplicate files being found in the jar file's manifest folder.
A pair of developers did some investigation, changed some config and "fixed" the issue - great.
Later in the day another pair decided to try actually making the application execute some of the new code's functionality in the cloud - just some relatively trivial calls to a RESTful service. The unit tests had all worked in development and the continuous build pipeline so surely there won't be any problems?
BANG!
For our application this was a runtime exception being thrown from a dependency of a dependency.
To cut a long story short, if your application needs to be deployed as one uberjar, don't blindly exclude configuration files from the resultant META-INF directory structure. Some systems expect and require configuration to be in place.
For my team I expect this to act as some motivation to set up some automated smoke tests that will interact with the web application inside the Cloud Foundry environment.
A pair of developers did some investigation, changed some config and "fixed" the issue - great.
Later in the day another pair decided to try actually making the application execute some of the new code's functionality in the cloud - just some relatively trivial calls to a RESTful service. The unit tests had all worked in development and the continuous build pipeline so surely there won't be any problems?
BANG!
java.lang.NullPointerException
at javax.ws.rs.core.MediaType.valueOf
For our application this was a runtime exception being thrown from a dependency of a dependency.
To cut a long story short, if your application needs to be deployed as one uberjar, don't blindly exclude configuration files from the resultant META-INF directory structure. Some systems expect and require configuration to be in place.
For my team I expect this to act as some motivation to set up some automated smoke tests that will interact with the web application inside the Cloud Foundry environment.
Monday, 9 June 2014
Deploying a Play application into Cloud Foundry
A week or so ago some colleagues gave a brief introduction to the local Cloud Foundry environment.
One of the main takeaways for me was that our application would need to be able to bind to a TCP port specified at runtime rather than have a statically defined one from a config file.
We spent some time looking into how to tell Play to listen on a provided port, and what might be involved in setting up a Cloud Foundry manifest file - then decided to just try deploying with something that we expected to fail.
We were pleasantly surprised to discover that the Java buildpack included enough logic to detect our application as being a Play application and looked after the port binding for us.
It wasn't a completely smooth process, as we did have to update the JDK version in the buildpack - which involved forking the Cloud Foundry github repository. Three lines of text changes was enough to get it up and running.
One of the main takeaways for me was that our application would need to be able to bind to a TCP port specified at runtime rather than have a statically defined one from a config file.
We spent some time looking into how to tell Play to listen on a provided port, and what might be involved in setting up a Cloud Foundry manifest file - then decided to just try deploying with something that we expected to fail.
We were pleasantly surprised to discover that the Java buildpack included enough logic to detect our application as being a Play application and looked after the port binding for us.
It wasn't a completely smooth process, as we did have to update the JDK version in the buildpack - which involved forking the Cloud Foundry github repository. Three lines of text changes was enough to get it up and running.
Subscribe to:
Posts (Atom)