Summary of “How We Use Jenkins for Continuous Deployment” (via tldr.io)

• Continuous integration is a must for software projects. It makes deployment stressless and lets you spot problems as soon as they arrive, not 3 months later.
• We take it one step further and use continuous deployment. Whenever one of us Git-pushes to master, the new code is tested and goes live right away.
• Jenkins makes it easy. With the Github plugin, you connect Jenkins to Github’s post-receive hook so that any code pushed to our repo triggers the Jenkins job.
• The Hipchat plugin lets Jenkins notify us whether the build was successful or not. That way we can react quickly if something goes wrong.

As all teams working on a web application, we had to setup a continuous integration server. This is a fairly well-known engineering practice, where you want your code to be built and tested regularly on the server so that you spot problems as soon as they arrive and not when you push three months’ worth of work to production. Also, it makes deployment a much less stressful experience, because you know it will work. You avoid getting in the situation of a friend of mine who could not have coffee with me because he was deploying and didn’t want to mess it up!

We also wanted to take it one step further, and use continuous deployment. As the name implies, this means that any new code pushed to the server will automatically be built, tested and then go live and be used by our users right away. It turns out that is fairly easy to set up -except for a few caveats-, and I will describe our setup. This by no means a step-by-step tutorial but rather a “here is what you can do” article.

Our Tech Stack - The Part Of It That Matters For This Article

Our server runs on Ubuntu 12.04 LTS, our version control system is Git (we use Github flow) and our code is hosted on Github. We chose to use Jenkins as the CI server. Even though it is poorly documented and has a definite ‘so nineties’ feel, it is very easy to deploy and intuitive. Basically, you use it to set up jobs that are run when you launch them manually or when an external event, such as a code push, is triggered. These jobs can be anything that’s executable, I usually use simple bash scripts but you can use any kind of script, makefiles and so on.

Install And Keep Jenkins Up And Running At All Times

Jenkins is contained in a WAR file, so you can simply download and execute it with java (command java -jar /path/to/jenkins.war). Of course, this is only suitable for testing purposes. In production, you will want to use an Upstart script so that Jenkins respawns if it crashes unexpectedly and starts on boot.

When Jenkins is up, you have access to a web interface to manage it (you can configure the port on which it listens). Make sure to enable security -I recommend matrix based security- unless you want anyone to be able to take control of your servers! One thing to watch out for is that you need to enable the “overall read” permission for the anonymous user, or else Jenkins won’t be able to communicate with third-party services - in our case Github and Hipchat. Pretty stupid behaviour I know, but at least it doesn’t create security holes.

Build On Push To Master

We have the Git and Github plugins enabled. The Github plugin enables us to connect Jenkins to Github’s post-receive hook. That way, whenever someone pushes to master (usually by merging a feature branch), our Jenkins “build” job pulls the new version of the code, builds it and test it. For us, that’s really a two-line script, as we check all modules in to Git.

If everything was successful, the “deploy” job is now called. It pulls the new version of the code in the live repository, then restarts the node server (since we use nodejs, we can overwrite the javascript files when the server is running without impacting it). Node starts pretty fast, so we only have ~0.1s downtime (no load balancer to achieve 0s downtime - for now!). And since we use an external store to manage sessions, nobody gets logged out.

Be Notified

The last part of the puzzle is how we get notified of the build result. We use Hipchat, so we installed the Hipchat plugin that notifies us of build results in a dedicated chat room. Most of the time it just says “Build successful”. But no sweat if a build fails, since the “deploy” job was not called our users don’t see anything wrong!

And That’s All There’s To It!

Yup. It is indeed simple enough to get a robust continuous deployment system up and running, that most of the time safely deploys your code through a simple git push on your part. I’m interested in anything you would have to say on this setup or any tip you’d like to share!

At Google I/O there were many interesting announcements: Nexus 7, Google Glass, etc. (Perhaps too many as one can say that Google is fighting too many ennemies on too many fronts). One news that drew my attention is the arrival of Google Chrome on iOs. Don’t expect browsing experience improvement you had on your desktop as this app is merely a graphical layer on top of Apple’s WebView from its SDK. Basically the engine is the same as Safari … just slower.

But that’s not my point. I want to talk about the sync functionnality that Google Chrome on iOS offers: by activating the sync on your different devices (desktop, iPad, iPhone…) you can open a tab you were viewing in one device on another one. The Continous Client becomes real.

So what is a Continuous Client you ask? Well the premise is simple: when you leave one device, you pick up your session in exactly the same place on the next device you use. Meaning your IM, Twitter, web browsing, applications, even your windows appear just as they did on the previous device. The situation I describe above would be obviated by this setup, allowing me to move from my laptop to iPad in a seamless manner which would in no way disrupt the activity I was currently engaged in. […] Put simply, you are placeshifting your computing experience from one device to the next with no break in your work, timelines, or conversations.

After using the cloud to store persistent data easily and seamlessly, one can now use it as a relay to get a continuous browsing experience across different devices.

We can moreover imagine various implementations of the continuous client to enhance our global user experience. For example, Invoxia with its business dock adopts the same vision for phone by bridging mobile and office calls.

My experience of these two continous clients is so magic but nonetheless so natural that I’m looking forward to future ones that will be invented to make our everyday life even more pleasant and interruptions-free.

And you, do you know another usecase where a continuous client architecture is already available?

On Fred Destin’s initiative, the big stars at Founders Forum, including Niklas ZennStröm (Skype), Chad Hurley (Youtube) and many others, shooted last week a funny and viral video to promote CodeClub. CodeClub is a brilliant action which aims at inspiring kids to learn code and creating a nationwide after school coding club for children aged 10-11.

Kids are the future, everybody knows it. Computer are, too. When we see what our generation’s geniuses made and how they revolutionized our world when computer science and coding were at their premises, one can only urge the next generation to dive into code as soon as possible.

Supporting this initiative is supporting a long term vision for our economy and our education system. There is no day without reading that there is a big lack of great programmers, that data-scientist is the hottest job at this time or that learning to code is a great move. So we should foster our kids to embrace this activity as soon as possible as informatics, hardware will be everywhere. By extending the base of people having the skills to program we foster the future innovation.

The earlier we start learning something the better we are good at it and the less we fear it. We belong to a generation where there is still a big proportion of people who are not at ease with computers or smartphones. Even an entreprising friend of mine judges that it’s too late for him to start learning how to code whereas he’s only 25! But have you experienced kids change of behaviour towards our world? I don’t think there will be many kids in 10 years who won’t know how to use a smartphone. And I do want to think that these kids in 10 years won’t be as reluctant to learn code as people can be today. Perhaps the qualifiers geeky or nerd won’t exist anymore, or have a very distant meaning, commensurate to what these people have created by now. Who knows ?

Last week, Rob Go from NextViewVentures explained why in his opinion people should think twice before starting a company: too much hype, harder to stand out, we are at the end of one innovation cycle and at the beginning of a new one which is less favorable to unexperienced and non-technical founders.

So to the question What to do instead of starting a company? he answers: Join the winningest company you can find in a sector you care about with people you like. Should you agree or not, this recommendation has its pros and cons but one can’t come to a decision easily. The most important lesson to learn comes at the end:

I think there is just the inherent satisfaction of being a part of a company that is making a big dent in the world. We’d all like to be the person who started that company, but there is a huge amount of pride to be had in being a contributor, even if you aren’t a leader. Also, scale and success give companies the right to do something meaningful. I often hear founders of failed companies lament “I realized that I just wasn’t that excited about X, Y, or Z market.” Well, the truth is, most people probably aren’t that excited about about helping merchants process credit cards (until Square) or the apartment rental industry (until Air BnB) or local advertising (until FourSquare), or the private car industry (until Uber) etc etc. Being part of a successful company that is shaping the future of an industry is usually inherently interesting and motivating, and it’s a great way to spend a few years of your life until the time is right for you to start a company that will do the same.

It’s a very interesting analysis as he doesn’t try to give a clear cut and general solution applicable to everybody. Instead he takes into account the personality of people who could be disposed to start a company, noting that founding a startup is not necesseraly the best fit for them. The true concern one should have is to make a dent in the world. Mark Bivens came to the same conclusion: People need to feel a part of something bigger and joining a startup could be the best answer to this feeling. It will never be be too late to found its company after such an experience, on the contrary it can only make things easier.