Today I attended the Jenkins User Conference, held in Israel, hosted by JFrog.
First off I have to say the event was very well organized. Great location, everything on schedule, no technical issues, some nice swag, and excellent food and drinks throughout the day (including afternoon beer!). Considering there were about 450 people there, that is no small task…
The guest of honor was Kohsuke Kawaguchi (KK), the creator of Jenkins, who gave an interesting keynote, with overview about the concepts behind Jenkins 2.0, and some anecdotes from the history of Jenkins.
The main theme of the conference was that Speed is Everything, as you can figure from JFrog’s motto, “Release fast or die”. Their view is that software today is about continuous update – you basically deploy your products once, and from there onward you struggle to update them as often as possible, as seamlessly as possible, without negative effects on the user experience. This raises numerous challenges which various vendors and open source projects are striving to solve.
There conference was packed with sessions related to the DevOps world, mostly about making things faster without losing control on the process. Liveperson, for example, discussed how they manage 6000 releases a year, with over 10K builds per week.
Personally, I found some sessions to be too abstract, or high-level, considering the audience is mostly Jenkins admins and other engineers. It felt like the majority of the audience were more impressed with the live demos or code snippets, than fancy diagrams and bullet lists. Still, we enjoyed the variety of topics, technologies and tools presented throughout the day.
Finally, it was interesting to notice a few issues were recurring, either in the presentations or the discussions which followed:
- Automating deployment is difficult to do, and difficult to maintain.
There are many cool technologies available today to help with it (e.g. Kubernetes), but for many companies, the cost of introducing such technologies – especially for existing, mature products – seems too high.
- Having a large number of build jobs seems unavoidable when doing things like MSA (Micro Services Architectures) or large-scale regression tests. This leads to multiple issues controlling and managing these jobs, while upholding common standards and behaviors.
- Almost every company develops its own dashboard and reporting capabilities on top of Jenkins. Managers – and also developers – want to know what’s going on, and Jenkins severely lacks in that department.
Bottom line – it was an interesting, fun, and thought provoking conference. I’d definitely go again next time.