Pages

Sunday, November 18, 2012

XPDays Kiev: Continuous Delivery Pipeline With Jenkins, Artifactory And LiveRebel

XPDays in Kiev was a success! Great crowd, interesting talks and fruitful discussions, socializing included.

Embedded are the slides from by import continuous.delivery.* talk which was surprisingly well received and it seems a lot of people are looking for ways to release and deploy continuously, even in the large organizations.

There are numerous different tools that could be used to organize the continuous delivery pipeline. The pipeline that I've demonstrated was built with Jenkins, Artifactory (Pro) and LiveRebel.

I'm not super happy with the build pipeline plugin in Jenkins. In the talk I had to spend time explaining why the flow is organized the way it is and why the build pipeline plugin behaves the way it behaves. It is just buggy... I should find time to fix it.

Arifactory's Pro version was just primarily because of the fact that artifact promotion feature is a Pro version and some of the REST APIs that I wanted to use were under Pro license. There are alternatives, but with Artifactory it was just much easier to show the relevant stuff.

LiveRebel - well, there's no real alternative to it. The attendees were really impressed how easy it is to deploy via LiveRebel and oversee the target environment.

The cool part is that all the tools integrate well via the REST API (or CLI) and you can build a very flexible pipeline if this kind of integration is available. What I also realized is that although everything can be automated in the pipeline, it shouldn't get on your way still - you should be able to go into any step and re-execute if needed.

Another critical feature is the rollback functionality. It is not just that you select the previous version of the app if something goes wrong. There's more things you have to keep in mind when organizing the pipeline (I'm not revealing it now :P).

Enjoy the slides! :)

Friday, November 2, 2012

Do you really get your IDE?

This is bit like a philosophical post. Just some thoughts regarding our perception of developer tooling. 

First - a question. Which IDE do you use? Eclipse? NetBeans? IntelliJ IDEA? Visual Studio? Vim? Emacs? Yeah, really - Vim counts as an IDE as long as you can configure it to behave like one. Or maybe Sublime Text, a really awesome text editor?

Second question. Do you leverage the full power of your favourite IDE/editor?

Mostly, people will say that the just use the IDE and I haven't really seen many people leveraging the power of refactorings, shortcuts, other awesome IDE features that are out there. Why? Lazy? Careless? Neglectful?

I was reading a nice theory article The IDE Divide, which is already 8 years old. The point of the article is that it points out two extremes among the developers: language mavens and tooling mavens. Language mavens are those who case about the deepest nuances in the programming languages and don't really want to rely on tools (or just don't have time to explore the features of the tools). Tooling mavens are the ones who are obsessed with learning (and creating?) the tools and not spending as much time discovering the mysteries of language features. The article also mentioned that it is enormously hard to be both, the language maven and the tools maven at the same time, since the time for learning all this stuff is limited.

But generally, I think, knowing the properties language and runtime is more important as it is the produced code that will eventually run on the system. The tools are just used to create the programs. However, I rather consider myself a "tooling maven" type of developer. Not that I don't care about the languages, no. It is just the interest shift towards tools for me.

Despite the above, I noticed something (or it is just my perception). When a the new-born programmer starts, you will first try to reach the comfortable level of using the language. Once you're successful, there comes time for you to write the programs more effectively - faster, using shortcuts… click, click, click. This is where the tooling kicks in. Eventually, you start appreciate those nice features of your IDE that help you to write the code more effectively. The next stage is when you realize that actually you do not write code as much as you read it, and then you will start to appreciate the features that help you to navigate the code, analyze it, maybe refactor it. Language becomes a bit unimportant.

I was chatting with Jacek Laskowski one day and he asked an interesting question: "If you're given awesome tools/components/frameworks to work with, would you really care about which programming language to use?". Really good question. I wouldn't care, I guess. You will learn the language anyway. Or you will learn the tooling anyway once you're comfortable with the language of your choice, because normally you would like to be more effective (this is my perception of curious programmers, I hope you are a curious programmer).

What do you feel when a colleague next to you just moves around the project like a pro and finds everything he needs just in fractions of a second, and types with shortcuts creating new statements with just a few strokes? And then you try to type: 'p' 'u' 'b' 'l' 'i' 'c' '_' 's' 't' 'a' 't' 'i' 'c' '_' 'v' 'o' 'i' 'd' '_' 'm' 'a' 'i' 'l' [oooops! a typo!]. Frustrating…

It is every so often I was keeping myself back from screaming at my colleague "just Ctrl+Shift+E !!!!" while the team mate was looking for the class in the project tree the name of which he did not remember.

 Modern IDEs have revolutionized the way in which we are able to work with the code. Sadly, most programmers are held back by some mysterious myth that if you learn the tools too much you're doomed as a programmer as you start depending on those tools. Don't be held back by such fears! Go learn some tooling instead - it will save you some time later!

Disqus for Code Impossible