A small help to get you into Continuous Integration

The more I use CI(Continuous Integration), the more I like. Sure it can be a “pain” in the beginning, but the gains are enormous. You can easily start getting results in a short period of time and improve you software development process.

If your team is not using CI, that’s no excuse for you. I’m here to help! You can easily setup, on your local machine, a VM(Virtual Machine) and run Jenkins inside. Then you can start using it. My purpose is not trying to convince anyone into using CI, but instead make it easier to start using.

For this purpose, I’ll give you a hand. Check my repository on GitHub: vagrant_jenkins. The README is self explanatory and you can use it as reference to get everything up and running. Let’s use this post to give just a little insight on what’s happening there.

If you follow the (few) instructions, by the end of process you’ll have a server running Jenkins. Cool uh? For a small effort you can start “playing” around. This set up is composed by two files: the Vagrant and the bootstrap.sh files. The Vagrant file will be used by vagrant to configure the VM itself and the  bootstrap.sh will be used to provision you server (basically install and configure everything you need).

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise64"
  config.vm.box_url = "http://files.vagrantup.com/precise64.box"

  config.vm.provision :shell, :path => "bootstrap.sh"
  config.vm.network "forwarded_port", guest: 8080, host:8080

  config.vm.provider :virtualbox do |vb|
      vb.customize ["modifyvm", :id, "--memory", "1024"]
  end
end

You can see here that Vagrant will download a “box”, corresponding to Ubuntu Precise Pangolin and use it as an OS. We also tell the VM that it should provision using our file, to forward ports so we can access Jenkins on our host and the amount of memory we want. Next comes bootstrap.sh.


#!/usr/bin/env bash


echo "Add Jenkins key"
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'

echo "Add PosgreSQL key"
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sh -c 'echo deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main > /etc/apt/sources.list.d/pgdg.list'

echo "Update repos"
apt-get update

echo "Install OpenJDK and Jenkins"
apt-get install -y openjdk-7-jdk jenkins git

echo "Install other packages"
apt-get install -y python-pip python-virtualenv libpq-dev python-dev

echo "Install Postgres"
apt-get install -y postgresql-9.3 postgresql-contrib-9.3

This one is even simpler. We just fetching and installing all the packages we need. The required one’s to run Jenkins are Java and Jenkins itself. The other’s you see there are some I normally use. If you don’t need them, just remove the corresponding code.

Please be patient the first time you run the instructions. There’s a lot being done, sot it might take a while.

By the end of it, you’ll have a basic setup which you can then use to manage your builds. Start using it, share with your colleagues, managers, supervisors, etc and you’ll see they will be interested in no time.
 

Advertisements

Code review: is it important?

First of all, what is Code Review? Let’s borrow from Wikipedia:

Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.

This definition gives a good idea of what Code Review is. In my opinion there’s more to it than only that.

I’ve worked with and without Code Review. While it’s feasible to work and produce software without it (many companies still do it) from experience I believe the advantages of using it are enormous.

Like the above the definition states, this practice aims at finding and fixing mistakes overlooked during initial phases of development. It will serve as a first phase of Quality Assurance (QA). These mistakes can be from a wide range of sources ranging from bugs in the code, to some problem due to lack of knowledge about the platform  being developed, or even misunderstanding the development task at hands. This by itself makes this practice very useful.

This technique it’s also important to help a developer improve his skills. I witnessed this in the first person. The fact that the code is reviewed by someone with more experience (in a specific programming language, framework, system, etc) will help a developer grow much faster. It’s invaluable, trust me.

Another point that I believe it’s very interesting in Code Review is the fact that it makes other developers aware of what you are doing. How many times have you been handed some piece of development from another developer who, by some reason, was unable to complete it (because of illness, left the company, etc) and no one knew exactly what was going on? This will guarantee that, at least, someone else is aware of what was done and can put you up to speed regarding the path followed.

A very interesting side effect technique is the fact that it allows your line manager to be aware of your skills and progress as a developer. This will enable your managers and colleagues to help you strengthen your weaknesses. It will also make your evaluations easier and much more accurate.

It’s my belief that when this practice is put in place many other advantages can be found. But, it has to be used conveniently! Several times I’ve seen conflict rise up  between reviewer and reviewed. That tension can appear from either sides.

This process should be an interactive, between the two parties. That means that it will be a back-and-forth of reviews. And it doesn’t necessarily mean that the reviewer will always be right. When the reviewed does not agree with something can, and should, make it’s on opinion “heard”, explaining the reasons for not agreeing. You would be surprised with the power of this process.

As the previous paragraph reveals, one of the most important skills for using this technique is good common sense. This approach should not be used as an opportunity to make negative criticism or even make others look bad. It’s my belief, and my experience gives me proof, that such an approach will in fact improve  software quality and will help everyone involved in the process to improve not only technical skills but also personal skills such as interacting with one another.

My answer to the question? Yes. A very big YES!