The LJC ran it’s ever-popular annual Open Conference on Saturday 23rd November, and this was the first time I’ve made it along. To say I was impressed was an understatement, and I’ll try and capture some more thoughts in a later blog post, but for the moment I wanted to share the slides from the main presentation I delivered “Chuck Norris Doesn’t Need DevOps”
Can’t see the presentation slides? Please click here http://www.slideshare.net/dbryant_uk/2013-ljcconf-chuck-norris-doesnt-need-devops
The original pitch for the talk was as follows:
“We all hear the term “DevOps” being thrown around on a daily basis, but what does it actually mean? With a little help from everyone’s favourite 80’s action hero, we’ll undergo a whistle-stop tour of the philosophy, culture and tooling behind this buzzword, specifically aimed at Java Developers.
We’ll also look at a real-world case study from Instant Access Technologies Ltd, and explore the key role that DevOps has played during a successful upgrade of the epoints customer loyalty platform to support increasing traffic. The core discussion will focus on the challenges encountered as we moved from a monolithic app deployed into a data centre on a ‘big bang’ schedule, to a platform of loosely-coupled components, all being continuously deployed into the Cloud.”
Thanks to everyone who attended my presentation! The feedback was most welcome, and the questions were great. If anyone wants to add anything further than please feel free to comment, email or tweet at me!
I’m currently working on a Java-based component which is utilising Solr heavily. We bundle the Solr core library dependency within a fat JAR (which we deploy standalone), and this dependency is managed via the de facto Maven approach.
After a series of new features were added to this component by a member of the team we suddenly noticed that the usual Solr logging to the console has stopped. At first we thought Solr had stopped working (which caused a little panic 🙂 ), but even though no logging was being displayed we could still access the web console, and everything appeared to be functioning correctly.
What most of the team didn’t realise is that during the addition of new features one of the developers also bumped the version of the Solr dependency from 4.2.0 to 4.3.0. The intentions were good – get the latest and greatest version, and the expectation is that a minor version number increase usually fixes bugs and adds a few pieces of new functionality.
However, this time around it was probably worth reading the release notes, as the Solr team have fundamentally altered their approach to logging in the 4.3.0 release http://wiki.apache.org/solr/SolrLogging
The fix for us was to include an appropriate log4j.properties config file within our component’s Maven resources directory. We were already including the slf4j and log4j dependencies within our component Maven POM, and so we didn’t need to perform any additional steps to incorporate these into the deployment artifact (our fat JAR) as mentioned by the Solr team at http://wiki.apache.org/solr/SolrLogging