04 July 2015
This blog contains the report of my attendance for JUC 2015 - Europe in London. I only wrote the bits that I find fresh to my brain and a set of keywords for researchability. More information is captured by workingwithdevs.com liveblog: day 1, day 2 (do note that we attended different talks).
A lot of talks in JUC were talking about blue green deployment i.e. Deploy green with new URL, slowly route everything to green, slowly remove blue when green is stable. At his talk, @sufyaan_kazi shows that CloudFoundry can act as the blue green deployment’s router implementation. CloudFoundry sells the idea that PaaS is the way to go for cloud as it will abstract out the cloud implementation hence not restricting your application to a single cloud. 12factor.net is a recommended reading.
@markusrendall did a live demo to showcase their blue green deployment in AWS. This is the best live demo shown in JUC. He added a twitter button to his web application during the demo and deployed it live. The conference attendees can hit the URL live and see that 50% of the hit don’t see the twitter button in their web page. Accenture referred this technique as A/B deployment. Seems like we haven’t reached a consensus yet on how we should call this technique.
Another deployment technique is shown by @mariocruz by using AWS Elastic Beanstalk. Elastic Beanstalk has an out of the box feature to instantly swap URL in between boxes. In summary, you deploy the new application in a new box, gain some confidence, switch your application URL to your new application by a push of a button. As a CTO, he also shows the importance of how he can rollback this URL swap from his mobile, again with a push of a button.
Good mind shift from @martincroker, summary:
Other than the Elastic Beanstalk showcase, @mariocruz also encourage us to adopt feature flags for a smoother and a more flexible app deployment. I think this is a synonym to feature toggle. He is using Netflix Archaius for his feature toggle implementation.
On the site note, he encourage the attendees repetitively that we should check out Netflix OSS as there are a lot of excellent freebies.
In the d1key and d1tiger, @kohsukekawa shows how he changed his deployment currency from wars to containers. This is an absolute game changer in continuous delivery paradigm, everyone in the deployment pipeline is interacting only with containers. Container is the new deployment package and Jenkins will be the one who is creating these containers.
During the transition, Cloudbees was faced with some challenges and has made some Jenkins Docker plugins to tackle them:
The sample application that @kohsukekawa used during the demo can be found here:
@CamundaBPM talk talked about how they are running 6 Docker hosts as 1 swarm. The interesting bit is that they are using Docker Plugin to point to Docker swarm. With this setup, the number of slaves are transparent to Jenkins and we can dynamically add more hosts to the swarm to scale Jenkins builds.
In the keynote however, @kohsukekawa was announcing that they will support kubernetes. Kubernetes features seems to be an overlap or even a superset of Docker swarm.
This is a funny analogy thrown by @martincroker during his talk.
| Pets | Cattle |
|---|---|
| Pets are given names like pussinboots.cern.ch | Cattle are given numbers like vm0042.cern.ch |
| They are unique, lovingly hand raised and cared for | They are almost identical to other cattle |
| When they get ill, you nurse them back to health | When they get ill, you get another one |
Credits for the table above from it20.info
Of course, he encourages the attendees to use more cattle. The live demo by @markusrendall was showing that all of their demo servers were cattles. They showcased a demo application that is using AWS Cloud Formation. When their JSON file is deployed in the demo, all of the servers, nginx, node app (with A/B deployment), Jenkins, etc, 8 VM with 4 separated subnets goes live. They had nothing but that single json file for all of those to be up. When those servers are up, @markusrendall continued with the demo and ended it by tearing down all those servers.
There are lot of good stuffs from @viktorclerc talk, check out his slides!
Some of the best bits I grasped:
Chaos monkey is used by @mariocruz to test his AWS instances. All these monkeys has now formed an army and become Simian Army.
An alternative to JMeter was used by @markusrendall during his live demo: gatling. Not much information about it were provided in the talk.
Masoon Jan is using FitNesse as a tool to do an acceptance test. This test is integration in his deployment pipeline.
This plugin was boasted last year and shockingly has been adopted by a lot of speakers in JUC. Workflow plugin is developed by @tyvole and @kohsukekawa in CloudBees. Jenkins core’s code has been modified a lot to support this plugin ever since the development of this plugin was started. Some of the plugin features are only available in Jenkins Enterprise e.g. checkpoints.
Jonathan Zenou shared a blueprint for his entire Jenkins setup. The blueprint can be found here. Supposingly anyone can just use that blueprint, spin up Jenkins and browse around the configuration (I haven’t tried this yet). He shared a lot of plugins that he used to tackle common problems in Jenkins. Most of these can also be seen in his slides.
Lots of times developers don’t bother to read the entire Jenkins output console and will ask you, the maintainer of Jenkins, to find out what the problem is. Most of the times the cause of the failure is obvious, but it is hard to find as they are in the middle of all other errors. Build Failure Analyzer provides a knowledge base by scanning your console output and provide a meaninful description of the error in the build page. Over time your knowledge base will grow and you will have less context switch!
Pushing for Continuous Integration requires dicipline from developers to fix the broken build as quick as possible. Showing a build failure with a big fat red panel will certainly help. Shared by Masoon Jan, he is using Build Monitor Plugin to achieve this.
In his talk, Robert McNulty was showing how he can retain Jenkins build history by using Groovy and Neo4j. He basically stores all of the build environment and any other specific information that he wants from a particular Jenkins build to Neo4j. After a certain period of time, this data can used for auditing or reviewing. He showed how Neo4j dashboard can display those data in an interesting graphs ouf of the box.
I didn’t manage to capture much information here, but if there is one speaker that talks about this topic it’s @IlkkaTurunen from Sonatype. He showed how putting a colour and code for compliance in Jenkins dashboard would help. The importance of compliance for large financial or technology firms were also shown by some statistics in Maven Central e.g. average downloads with known vulnerabilities, percentage with known defective parts, component downloads with known defects older than 2013, percentage with known defects older than 2013, etc. I vaguely remembered that he was showing “Application composition report”, most likely it’s a part of the software that they are selling called Sonatype CLM.
Test code as a source code, Infrastructure as a code, everything as a code, the new common language in DevOps is code.
Not all slides are made available by @jenkinsconf yet. Latest update.
