Posts Tagged ‘artifactory’
It was JFrog‘s second QCon London, and it just gets better. Imagine: even the London weather was perfect, not to mention the sessions, booth traffic, show organization and food (what, you say, good English food? Well, great IndoPak food, at least). Due to high demand by sponsors, the exhibition took place on two floors (as opposed to one floor last year). Our JFrog booth was located in the same place as in 2011. We’re getting used to the place and are looking forward to returning next March!
The speaker panel was extremely impressive, featuring gurus like Martin Fowler, Adrian Cockcroft (the man behind Netflix’ cloud), Dwight Merriman (co-creator of MongoDB), Damien Katz (creator of CouchDB) and Rich Hickey (creator of Clojure).
The conference started with two training days – six full-day tutorials each. From my perspective, the most interesting two tutorials were “Cloud Architecture” by Adrian Cockcroft, where he shared the architecture, best practices and decisions behind Netflix’ cloud (which Artifactory is proud to be a part of) and “Continuous Delivery” by ThoughtWorks’ Tom Sulston (that’s as close to the roots of the famous “Continuous Delivery” book as you can get). For me, the most fascinating thing in the Continuous Delivery process as ThoughtWorks sees it, is that its virtues are exactly the same as we based our Artifactory upon back in 2006: DevOps automation and rapid release cycle. We appreciated the validation of our concept.
The remaining three days of the week were all-day sessions. It’s impossible to review such a significant number of talks in one blog post, so I’ll concentrate only on the excellent keynote addresses (with one exception).
Martin’s conference-opening keynote speech was about data. The main feature of modern data is that it is bigger than you think. Polyglot storage in general and various kinds of NoSQL look like the right solution.
My favorite keynotes are usually the evening ones. A beer in your hand makes any amusing talk even more enjoyable. One named “Developers Have a Mental Disorder” I couldn’t miss! Greg Young gave a great show, funny and entertaining, about serious dilemmas in software development that we, the developers, prefer to ignore. The brightest example, of course is the downside of DRY (did you ever think about one?). By removing duplication, we increase coupling, which can be much worse.
Thursday morning’s keynote address was delivered by Rich Hickey. He spoke about the differences between “Simple” and “Easy”. Sounds pretty similar, but in fact they are very far from being the same. Antonyms to the rescue: simple vs. complex, while easy vs. hard. Now it’s clear – we need to strive to prevent and remove complexity (go simple) without being afraid of the hard. Choosing easiness may end up creating complexity. Things which are easy, but complex, include OOP, mutable state, imperative loops and frameworks (especially ORM). Things which are simple, but not necessarily easy (at least not until you get them), are LISP-ish languages, like Clojure.
My session also took place on Thursday, in relatively small room, about 70 people. I was more than happy to see that it was almost packed. I spoke about building trust in your build process by selecting the right tools for the job (of course, we consider Artifactory as one). I also spoke about the problems of DevOps in the word of Continuous Delivery in the cloud and the rapid release cycle of SaaS applications. I stressed the huge timeshare of binaries in ALM process and the importance of using a tool that really understands binaries to deal with them. That’s exactly the reason why we developed Artifactory.
Half of my session was dedicated to live demos, which went smoothly, incredible as it may sound. According to the feedback received, my talk was well accepted, and hopefully will be useful to some of the attendants for building easier and more reliable release processes. The Q&A session continued at our booth, where we repeatedly did live demonstrations and received excellent feedback each time. If you want to get a feeling of my talk, here’s the slide-deck.
Friday was the last day of the conference. It started hard with a highly technical keynote address by John Allspaw with a scary name: “Resilient Response In Complex Systems”. For someone like me, who doesn’t deal on a daily basis with Disaster Recovery, the session was astonishing. Looking behind the curtain of that kitchen reveals a totally different way of thinking and planning. It may be how individuals and teams have to perform during a disaster (e.g. personal heroism is bad even if successful; it sends the wrong message to the team), or simulating disasters on live production systems (I never could even dare to think about that). The most obvious, but still eye-opening advice that John gave is to learn from successes, not only from failures. It can give us a lot of information and happens much more frequently, no? The only organization with which I am familiar that embraces that technique is the Israeli Air Force.
To sum up, the conference was great by every measure: technical sessions, attendance, networking, Artifactory exposure, and after-show quality time. Thank you, InfoQ, for this wonderful event in London. QCon was a great starting shot for JFrog’s “Busy March”. You still can catch Fredric and Yoav giving talks on various events in US and Europe.
The problem of dependency management is neither new nor original, it exists in all development platforms, and .NET is no different.
Let’s go through different solutions and see how they perform. I’ll list them here in no particular order.
As AlphaCSP‘s training guy I deliver a lot of trainings. They come in different flavors, on different topics, and in different companies. The common in all of them is the problem I encounter on labs setups.
First, problem definition:
Let’s take, for example, some serious global financial company, which needs training in Spring, Hibernate and JAX-RS. My contact point is a nice Training Activities Administrator. She just organized “Micro-Expressions Training for HR” and her next task is to organize my Java course. What do you say, will she be able to install IntelliJ IDEA (or Eclipse?), Spring 3 bundles, Hibernate dependencies and Jersey? And yes, the classroom network is detached from both Intranet and Internet (BIG financial company, remember?). Oh, I almost forgot a bonus – the training workstations rollback all changes after every restart.
Now, here are two possible provisioning solutions:
- Come over day before for installs. Well, probably the classroom is occupied with another course. If not, the guy that should let me in the classroom, the network, and the computers is busy, sick or in Thailand, but probably all three in the same time. Ah, and I have another work to do on this day! And the customer won’t pay for it anyway. You got the point – bad idea.
- Prepare the labs on CDs. Well, it generally works, most of the software courses delivered that way, one successful example is SpringSource trainings. You get nicely branded CD full of all you need – The IDE, the dependencies, and the labs source code. Good stuff, really. It works for SpringSource because of the high volume of catalog courses they deliver. They have a stock of identical CDs they use during every single training, worldwide. When it comes to tailor-made courses, things are different. No course is similar to any other course, the topics, installs, dependencies and exercises are unique set each time. That rather complicates the CDs craft – composing, burning, labeling. I don’t say it’s impossible – I did it for each and every course, but it’s a real PITA. And thanks to the reverting workstations, students will have to copy, extract, setup, define variables every day from scratch over and over again. Did I mention PITA?
And there is a third solution. The best one. You can use Enterprise Repository Manager to recreate students environment in a couple of minutes in any given time. Now, it rocks. It really is. Watch the steps:
- Customer Requirements
- Two simple installs, every Training Administrator and/or Sysadmin can manage:
- Create .m2 directory under user home for Maven user settings.
- Permission to connect your notebook to the class’ Intranet. It is isolated, the machines revert themselves, shouldn’t be a problem.
- Exercises development
- Develop the exercises on your notebook with all the Maven goodies – pom.xml, dependencies, superb IntelliJ-Maven integration (or Eclipse?).
- Install Artifactory locally (you’ll see why Artifactory and not Nexus in the following steps). I mean – download and unzip, heh. Run it (not even as a service)
- Import your local repository to Artifactory (can’t do it in Nexus #1) – zip it and make half-dozen of clicks in Artifactory UI.
- Deploy the exercises to the local repository. They probably won’t compile – they are exercises, right? Then just zip them and deploy from UI. Students will download them through Artifactory UI.
- Take the Artifactory down. You are ready to go to class.
- Exercises delivery
- “Good morning, students!” – deliver the hell of the course, get to the hands-on part.
- Connect your notebook to the class’ Intranet, get dynamic IP (yap, dynamic is good enough).
- Get Artifactory up and running.
- Let the students browse to Artifactory’s homepage. There they will found Maven Settings Generator (can’t do it in Nexus #2), which will generate settings.xml to work with your instance of Artifactory from their machines. All they need to do is check “Mirror-Any”, select “repo” and save the generated file under .m2 directory. That’s all, their machines are fully configured to get all the dependencies needed for Spring, Hibernate, Jersey, and whatever you need for your training.
- Let the students browse the repository to download the exercises zip, unzip it, export Maven project into IntelliJ IDEA (or Eclipse?) and just start working!
As you saw, using Artifactory as labs delivery platform dramatically simplifies both lecturer’s and student’s life, enabling rapid exercises development and rollout without any preparation from student’s part and minimal preparation from training organizer’s part, all those thanks to Maven2 dependency management capabilities, good IDE Maven integration, and, of course, Artifactory’s ease of use. And frankly, there is nothing I love more than ease of use. Maybe only chocolate ice-cream.