Live and let build


Last Thursday (1st of July), I attended JFrog’s build seminar – To build or not to be.  The convention were led by some top experts on the subject – Yoav Landman (JFrog CTO), Fredric Simon (JFrog Chief Architect), Hans Dockter (founder and project leader of Gradle) and Kohsuke Kawaguchi (creator and leader of Hudson build server, i.e. Hudson-CI).
The seminar incorporated reviews and introductions from all relevant aspects of project maintenance related to build issues.
Landman spoke of modular systems and separation of  concerns between different modules. As a good example, he referred to project Jigsaw and how beneficial it can be for both developers and end-users (e.g.: You don’t have to download and install the entire Java runtime – include UI libraries - when you’re running a simple console application). Landman stated that the world is gradually migrating to modular system builds, emphasizing its contribution to evolvement of greater and better services.

Dockter provided a delightful introduction to the Gradle build tool and an insights on some key features inside Gradle. As perceived by others and myself, Gradle is the legal heir of Maven. It is everything that Maven is and is not. It's refreshing approach to build issues, dependency management and incorporated DSL based on Groovy makes it a winning candidate, leaving all competitors way behind.

image Another highlight was Kohsuke Kawaguchi pushing Hudson to the limit. Kawaguchi proved once again that open source projects can have a commercial and professional grade. Kohsuke reviewed some major features of Hudson CI and elaborated on distributed building process. At modern times, running through a complete build cycle (resource gathering, compilation, unit testing, integration testing, packaging, deploying ….) can consume quite a time.
Like other major-league players – Jetbrain’s TeamCity and Atlassian Bamboo – Hudson CI provides the PXE plugin that allows you to add and drop build machines in a matter of a clicks. Hudson has a true distributed build model and work-load distribution mechanism (allowing to compile the project on one machine and run tests on another), but that’s a subject for another discussion.

The finale appeared with the exotic image of Frederic Simon, a veteran in the Java landscape. Simon took us to a hands-on tour with Gradle, Hudson CI, and its excellent integration with Artifactory.
Speaking with some attendees, I realized that this presentation visualized to them how healthy builds can save your time, and thus save you money.

Final words
Artifactory has a great integration with local build tools, such as Gradle, Maven and Ant/Ivy from one side and build server – such as Hudson and JetBrain’s TeamCity – from the other side. The seminar illustrated it both.
My personal note from this seminar, is that every organization – or even better yet – every project, must have its "build officer” (Configuration Manager), a person responsible of all build issues. I have encountered this position on some projects, but it was mainly of large companies with large-enough infrastructure to demand such a standard.
I think that every project, no matter how small, should have such an expert. As I don’t expect an enterprise-grade project to run without an architect (or even senior developer that fills that title), I wouldn’t expect to run without a Build Officer.
You can find more photos from the seminar here.

On-click deployments - From fantasy to reality (part 1)


Before describing my doctrine about deployments, and One-clink Deployment (OnCD) in particular, I would like to review what 'OnCD' is.
Imagine a café scene, located in the middle of an oldish pedestrian mall in central European town.
A man in his 30's, well dress with a Gentleman's manners, sits by and drinks his espresso with small sips. Suddenly, within the crowd's noise, a cell phone rings.
The man pulls out his chic phone, listens for a second and mumbles few words into mouse piece.
He sets his phone aside, opens his laptop, tap a few stokes on it and smiles to himself. Closing back his computer, he returns to his awaiting espresso. Taking another sip, stretching back and enjoying the warmly sun…
Watching from the side, some would say it’s a classic scene from a spy-movie, where an agent gets a phone call about ransom money or an order to activate a bomb remotely.
However, as an open-minded technical person, with just a bit of imagination, I would suggest an alternative. Listen to this one:
An IT personal -  say system administrator - gets a phone call from the project manager, learning that all bug fixes and latest features were committed to the source repository. It is now time to execute a build-cycle to compile and deploy the application to a production site, or at least to the local test field. All done with a few key strokes.

My theory about deployments
It's not a fantasy. If you have a healthy build cycle, you can enjoy quality time in Europe (or an exotic place in Asia) - during day work - and perform builds with only few clicks in only minutes of your precious time.
On the other hand, if have a problematic build cycle, you can expect passing some nights at work, reviewing textual log files, running ugly scripts and eating lots of Pizza (that's not that bad, but it's not healthy either).
Within the following entries on my blog, I will share with you some of my experience related to healthy build cycle, where you can compile, package, deploy and install - all with just a few clicks, ideally with a single click.
I will use a traditionally build server, such as Hudson CI and Jetbrain's TeamCity to do the hard work for me.
Last, I will demonstrate the strength of a remote repository, such as Artifactory, that empowers the build cycle and enhance our way of life.

A new blog comes to life !


After many doubts and thoughts, I decided to create a new blog for all my posts around the cyberspace.

The door is open, everyone is welcome to comment!