Atlassian DevOps Event Impressions

Today I attended an event, organized by ManageWare, titled “Bridging the Gap Between Dev & Ops”, focusing on Atlassian’s tools suite. JIRA is a very popular tool here in Israel, so the main theme of the event was to showcase how productivity and collaboration can be increased when integrating JIRA with other tools.

There were quite a few presentation (detailed at the end of the post) on various DevOps-oriented subjects, such as CI/CD pipelines, monitoring and reporting. Nothing revolutionary, but it was nice to see how a good integration between various tools (not just Atlassian ones…) can really make things flow faster and help focus on generating value for the business.

I only wish some of the sessions were longer, there was a lot more to see; unfortunately, due to time constraints, most presenters had to rush through their materials.

And finally we had some fresh Pizza and ice-cold beer ūüôā

The presentations:

Continue reading


CI with ClearCase Base: The Road Less Traveled

We spent the last year or so building and maintaining a Continuous Integration (CI) system for our major development group. And it was incredibly daunting and frustrating, considering we had to build it around a legacy and problematic version control system like ClearCase Base.

In the textbooks it seems pretty simple: every commit (check-in) to the repository triggers a build, which in turn checks out the latest version of the repository from source control, and run the build process. This way, if a build fail, you know exactly who broke the build Рthe person who performed the last commit Рand if it the build passes, you have full traceability between the build artifacts and the source code they were built from.

Now, let’s try that with ClearCase Base.

Continue reading

Jenkins User Conference 2016 – Impressions

20160703_161012 20160703_214802

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.

Continue reading

Netflix build process

Netflix are well known for their excellent deployment capabilities.

In this article they go over their build process and tools, from compiling code all the way to production, and presenting their current challenges and future plans.

A highly recommend read for anyone who is interested in doing DevOps the right way.

Branch in Code (a.k.a. Config Flags)

Inspired by an article on CM Crossroads¬†I stumbled upon lately, I’d like to give a high-level overview on this concept, commonly use in web site developments and can also be applied¬†to cloud applications. But most people (like me) who work with ‘installable’ software never heard of it, and if they did, they regard it as an alien concept that just can’t work.

The short version is this:

  • Your software is a service. There is only a single deployment of that software, which means a single relevant codebase.
  • Hence there is no point of doing branching and merging in your source control. Everyone commits to the mainline
  • Instead of branching, developers wrap every piece of new code with some condition that can be controlled externally (e.g. a flag in a config file, user properties, server environment, etc.)

This way you can “switch versions in runtime”. Which lets you do things like:

  • Get rid of feature branches and merges – just deploy the “dark code” (partial/untested code) for a new feature ahead of time and, when the feature is ready, you can easily turn it on (and off if problems appear)
  • Roll out an update gradually and selectively
  • Rollback an update in a matter of seconds
  • Offer different UI experience to different users
  • Test new code on production servers (by conditioning based on e.g. user id or IP range)
  • And more…


  • The code can become somewhat “ugly”. Although many of those flags eventually get removed from the code once they don’t have a use in production.
  • ‘config file explosion’ – there are several different approaches regarding controlling the amount and lifespan of configuration flags
  • ‘mysterious flags’ – here too, there are some ideas about maintaining proper documentation as well as performing cleanup/refactoring as needed.