Continuous integration with Hudson

Continuous integration has become common practice for teams focused on ensuring code quality throughout the software development lifecycle. In this article, Nicholas Whitehead introduces Hudson, a popular open source CI server.

Continuous integration (CI) is a set of practices intended to ease and stabilize the process of creating software builds. CI assists development teams with the following challenges:

• Software build automation: With CI, you can launch the build process of a software artifact at the push of a button, on a predefined schedule, or in response to a specified event. If you want to build a software artifact from source, your build process is not bound to a specific IDE, computer, or person.
• Continuous automated build verification: A CI system can be configured to constantly execute builds as new or modified source code is checked in. This means that while a team of software developers periodically checks in new or modified code, the CI system continuously verifies that the build is not being broken by the new code. This reduces the need for developers to check with each other on changes to interdependent components.
• Continuous automated build testing: An extension of build verification, this process ensures that new or modified code does not cause a suite of predefined tests on the built artifacts to fail. In both build verification and testing, failures can trigger notifications to interested parties, indicating that a build or some tests have failed.
• Post-build procedure automation: The build lifecycle of a software artifact may also require additional tasks that can be automated once build verification and testing are complete, such as generating documentation, packaging the software, and deploying the artifacts to a running environment or to a software repository. In this way artifacts can quickly be made available to users.

To implement a CI server you need, at minimum, an accessible source code repository (and the source code in it), a set of build scripts and procedures, and a suite of tests to execute against the built artifacts. Figure 1 outlines the basic structure of a CI system.

Figure 1. Basic structure of a CI system

The system components come into play in the following sequence:

1. Developers check new and modified code into the source code repository.
2. The CI server creates a dedicated workspace for each project. When a new build is requested or scheduled, the source is retrieved from the repository into this workspace, where the build is then executed.
3. The CI server executes the build process on the newly created or refreshed workspace.
4. Once the build completes, the CI server can optionally invoke the defined test suite on the new artifacts. If the build fails, registered individuals can be notified by email, instant messaging, or some other method.
5. If the build is successful, the artifacts are packaged and transmitted to a deployment target (such as an application server) and/or stored as a new versioned artifact in a software repository. This repository can be part of the CI server, or could be an external repository, such as a file server or a software distribution site like Java.net or SourceForge. The source code repository and the artifact repository can be separate, and it is actually possible to use some CI servers without any formal source control system at all.
6. CI servers usually have some sort of console where projects can be configured and debugged, and where requests can be issued for operations such as ad hoc immediate builds, report generation, or retrieval of built artifacts.

Hudson is a free and open source product hosted at Java.net It was originally written by Kohsuke Kawaguchi, a staff engineer at Sun Microsystems, who announced its release on his blog in February of 2005. Hudson has since had approximately 154 releases.

Here are some of the reasons why I like Hudson, and why I would recommend it to you, barring any unusual requirements:

• Of all the CI products I've used, it is by far the easiest to install and configure.
• Its Web-based user interfaces are very friendly, intuitive, and responsive, in many cases providing immediate Ajax-enabled feedback on individual configuration fields.
• Hudson is Java-based (which is useful if you're a Java developer) but is not limited to building Java-based software.
• Hudson is cleanly componentized and offers a well-defined and documented extensibility API in the form of Hudson plugins. This has in turn led to a large library of Hudson plugins that extend the functionality of the server; these are freely available and installable from the Hudson console.

Resources:
- Get the latest Hudson WAR file here or here.
- Download apache-tomcat-6.0.18.exe to install Tomcat on your Windows machine. Download JBoss 4.2.3.GA for a Linux environment (look for the file named jboss-4.2.3.GA.zip).
- If your Hudson server cannot connect to outside resources, you can download the plugins you need from the Hudson Website.

Update your Resume!

What you say? You like your job? Have no intention of leaving? Why would I update my resume?

Well, I too enjoy my job and the company I work for. I’m not talking about finding a new job, I’m talking about managing your career. In this day and age, individuals need to take responsibility for career management.

A good time to review your resume is once a year, around review time. I know not all companies do yearly reviews. Maybe the review you get is not as valuable as it could be. Regardless, set up your own time to review your career progress.

From now on, update it so it reflects your current experiences. Take a good look at the what you have done in the past year. How have you progressed over the last couple years?

Next, set up some goals for yourself in the next year. I like to focus on four general areas:

Technology: What technologies should I make improvements on? What new technologies are coming up? How can I better use current technologies?

Processes: Learn about new agile methods? Learn about how others are using the methods and improving them. Learn a process you may be less familiar with like configuration management techniques.

People skills: Don’t forget the soft skills. I’m not necessarily talking management here (unless that is your goal). Leadership can come from anywhere. Unless you are a “one programmer team” you work with others. Whenever you are attempting to influence someone, you are using leadership skills.

Business: We don’t work in a vacuum. What business is my company in? What areas of that business can I get a greater understanding?

Once you have a list of general topics you want to focus on, make then concrete. Pick enough that pushes you to grow in the next year, but not more then you can effectively commit to.

Next, make each goal measurable. Write down something that you can do in the next year. Write the goal such that it is obvious when you done.

Put a date with the goal. If the goal has multiple parts, put dates to the sub goals as well. For example:

Technology goal: Attain a greater understanding in .NET framework.

• Read the book by
• Choose an application in which to use your new skills by
• etc…

People skills goal: Improve communication skills.

• Choose a topic you can present on by
• Prepare a presentation by
• Learn foreign languages: Japanese ...
  
• Present to your peers at a lunch-n-learn by
• etc..

Next year, you can review the goals you accomplished and add them to your resume.

These goals don’t all have to be specific to the company you work for. It makes sense that they are so you can improve your career opportunities there. However, add some personal goals as well. I might want to learn a new language like Groovy or Python even though my company is a primarily a Microsoft shop or learn the.NET framework if your company is a Java shop.

You have to take charge of your career. Your company may or may not take an active role in this. Like many things in life, if you don’t manage it, it will most certainly manage you.

What It Takes To Be A Great Technical Lead

Most teams have some kind of technical lead in place. They’re often referred to as the ‘dev lead’, or the ‘lead developer’ or the ‘lead programmer’ or whatever. Some people are great fits for this role, and some simply aren’t. Below is my list of what i think makes for a great technical lead. Note: i’m not claiming that i live up to all of this, although i do try to.

• You obviously need strong technical skills. You are responsible for the final result, so you better make sure that there is a solid technical foundation for the team to build upon. This doesn’t mean that you should build this foundation entirely yourself. Preferably, you involve your teammates into this as much as possible. You’re also responsible for fixing technical issues that your teammates can’t solve. You either fix it, or when that’s not possible you should figure out an acceptable workaround. Be sure that your teammates are fully aware of the details of the solution or the workaround.

• You have to be able to teach your teammates. As a technical lead it is your duty to improve the skills of your teammates. No matter how good you may be, if you can’t transfer that knowledge and those skills, you’re not doing a good job as a technical lead. If there are some core principles or practices that you want them to apply to their work, you need to make sure that each and every one of them really ‘gets’ it. You need to be willing to invest the time and effort it takes to achieve that.

• You need to trust your teammates. This isn’t always easy, especially when it’s about someone who hasn’t progressed as far or as fast as you would’ve liked him to. But it is definitely necessary. If a teammate realizes that you trust him, he will usually respond with improved output. It might not always be everything you hoped for… but either his effort, or the quality of the work will improve. Keep trusting the teammate, and eventually both will improve. Which actually happens a lot sooner than most people would think.

• Stimulate self-organization. I know a lot of people don’t believe in self organizing teams. And to an extent, that disbelief is somewhat valid. There always has to be one or a couple of people who have some kind of leadership role (be it officially or not). Those leadership roles do not prevent self organizing teams though, in fact, i’d say they enable them. Do not simply assign tasks to your teammates all the time. Organize planning meetings where members can choose the tasks they will do. Make sure there is always some kind of balance though. You really need to prevent that person A always gets the shitty tasks or that person B always get the funnest tasks. Mix it around it a little and try to make sure that the fun/shit ratio is never out of whack.

• Don’t keep the coolest technical tasks for yourself. If the project requires some kind of technical research to use a new library or to figure out an approach to a new problem or whatever, make sure all of the teammates get the chance to do these kind of things once in a while. It’s not always possible to do so, but when you can, it really pays off. Morale goes up, trust goes up in both directions, and everybody improves.

• Try to prevent overtime as much as possible. If you’ve been given an impossible deadline, try to convince management that it’s simply not doable. Fight for it if you must. But realistically speaking, you can’t extend every deadline they throw at you, and sooner or later you’re gonna be in a situation where you and your teammates are going to have to put in some overtime to get everything done on time. Don’t tell your teammates they have to do it. Ask them if they want to do it. For some people, this doesn’t always make a difference but for others, it makes a huge difference. And this one is very important when you’re doing overtime: do not go home early while your teammates are still working, because it will come back to bite you in the ass eventually.

• Remember that you are responsible for the final result. If something goes wrong, it really is your fault. Never put the blame on one of your teammates. Not within the team, and definitely not when managers are present. If a teammate screwed up and the problem made it into the production version, then that is your responsibility and your fault.

• Give credit where credit is due. If a teammate did a great job with something, give them that credit and make sure everyone else knows about it too, especially management. Never take credit for the work of a teammate because that is simply one of the lowest possible things you could do.

• Finally, you need to realize that your teammates are not your developers. I’ve often heard technical leads say things like “yeah, my developers…” or “my guys … “. No. They are your teammates, no matter what your role in the team is. Having a leadership role does not mean you are the boss of your teammates or that you can boss them around. If anything, it destroys morale and the results of your team will suffer tremendously from it.

Resources: Davy Brion