Continuous Integration in 15 Minutes with Hudson

My motto: If something goes wrong, I want to know it now. Continuous Integration is always one of the most useful Agile practice I adore. It remove the phrase “But it was working on my machine .. yesterday!” out of the equation by putting a central environment that the build must run on. Most people might be more familiar with Cruisecontrol, but the lack of snappy setup and configuration for newbies is one of the big downsides it has. I was just introduced to Hudson recently and really likes the simplicity it offers. I recommend this to teams that start using CI, because it is really easy to set up.

CI Basics

First, let me talk real quick about CI, to summarize its benefits and allow us to see how Hudson comes to play with that. Continuous Integrations in the wild usually follow these steps.

1. One of the Developers in the team checks in code to a code repository (SVN, Mercurial, etc).
2. Hudson sees that there’s a new code and checks out the code in its own workspace
3. Hudson run the build script (usually Ant, or the increasingly popular Maven) that is checked in the code. The build script usually follow these steps ( I will surely blog more about this later ).
   1. Checking
   2. DB
   3. Generating code
   4. Compile
   5. Run automated test
   6. Run code analyzer tool (Static Analysis, Code Metrics , Test Coverage)
   7. Deploy the compiled code on test server
4. Hudson gather build results and compile a report (compile pass/failed, number of test passed/failed)
5. Hudson publish a report on the website, and send out (emails/rss/twitter) to the developer that breaks the build
6. The developer has to take responsibility to fix the error and commit in the fix

Installing Hudson

1. Hudson is distributed a form of (.war) file. Download the latest one from their website.
2. Prepare any Java Servlet container. Tomcat, would do. For windows, I suggest installing it as a service.
3. Use Tomcat Manager to upload and deploy hudson.war
4. Goto http://localhost:8080/hudson
5. On the left menu, goto “Manage Hudson”, then “Configure System”. Enter email server information

Configuring the build

1. Each build project is called jobs. There’s a link to create one once you browse to hudson, click on it.
2. Enter the job name. Choose “Build a free-style software project“.
3. In Source code Management section, choose the one you use. Provide the path to your project source repository.
4. In Build Triggers, select how often we want Hudson to grab the source code. In regular standalone projects, we usually do it every time a developer checks in code (“Poll SCM”). The parameter is a schedule in cron format. Every fifteen minutes ( */15 * * * *) should suffice for most projects. Note that this does not mean that we will build every 15 minutes, it means that Hudson will be checking for changes in the SVN every 15 minutes.
5. In build section, select add build step. Choose “Invoke Ant” and provide the target name. If the build.xml is not at the root of the repository, choose “Advanced…” and provide the ant file path.
6. In Post build actions, select Email notification and enter a list of everybody in your team. This will make Hudson send out an email to everybody when there’s a build broken.

Establishing Fix-the-Build Culture

This is probably the most important thing you need to do, even more important than the tool itself. This is when you get team members together. Introduce their new neighbor, the build server. Then establishing the team rule of “You break the build, you fix the build”. This does not mean that the junior member will be entirely on their own when problems arise. But he needs to be responsible for grabbing the right people when something happens and everybody is accountable for their commits.

Making such rule would ensure that you would have the near-shippable quality product every day. Well… something that compiles and automatically tested at least .

คนข้างล่าง

เพลงนี้อัดกับน้องเดฟไว้ตั้งนานแล้วล่ะ ชอบมากเลย น้องเดฟก็เสียงดีมากๆ เลยด้วย โพสไว้ตรงนี้แหละ เผื่อวันหลังมาค้นดูจะได้หาง่ายๆ นะ

OpenUP

OpenUP is what you get when you try to fit Agile practices in to the Unified process framework. The author(s) claim that the resulting process is an Agile one, a statement which might raise some eyebrows when looked closely at the specific practices prescribed. This paper serve as an introduction to OpenUP and provide rationales why OpenUP is considered Agile according to the Agile manifesto.

Using OpenUP

We can start with reading about OpenUP from the official site. While this could be a little overwhelming at first, following these step should help us make sense out of OpenUP a little faster.

1. The obvious starting point is the Introduction Page. There are two levels of planning in OpenUP. First, there’s a project plan that roughly define iterations and milestones to accomplish for all phases. Then we move on to iteration plan (comparable to SCRUM’s sprint) which pretty much defines what is to deliver in each increment. Iteration plan consist of multiple work items (tasks) to be completed.
2. Read about all practices in general. There are two types of practices in OpenUP: Management and Technical. Majority of these should be very familiar to those who use Agile in their everyday’s life.
3. Skim description of roles
4. Open up a section about work products ( artifacts ). See the example of project plan and iteration plan under “Project Management” section and take a quick look at them. Note that each phase are subdivided into iterations with goals as an acceptance criteria for that iteration.
5. Read about activities in each phase. These are obscurely placed under the “Delivery Processes” section. Click on the name of each phase to open it up. Then click on the (Phase name)[1..n] picture to see what’s inside.
6. Now we should be able to see an overall view of each phase. We are likely to refer back to this when we are doing the project/iteration planning. Click on the activity name (eg. Initiate Project) to see the step details, roles involved and work products expected.

Differences from XP/SCRUM

In principle, OpenUP looks like any Agile processes with a little more detailed practices defined. However, those who exposed to XP/SCRUM flavor of Agile (likely to be majority of us) would quickly see these differences.

• Phases (Inception, Elaboration, Construction, Transition) are defined – This obviously comes from an influence of Unified Process.
• Roles and responsibilities are defined
• Work products that are expected as a milestone document (Project plan, risk list, architecture notebook, etc.)
• Explicit risk management
• Encourage early architectural design
• Project plan with estimated dates for completion

My take on OpenUP

• I really like the idea of having a project plan. As much as we hate it, deadlines are part of life. The first thing you need to answers to management is the one million dollars question (sometimes literally!) of “when it’s going to be done?”. This might be challenging to answer with typical SCRUM backlog as things are being added all the time, so we really have control of only what’s in each iteration but not the overall plan for the project.  Having the project plan laid out a big picture of what’s going to be done, help us track if the project is really going to be finished in time and help management make the right decision dealing with big changes. This is what (conceptually) happened when I used OpenUP:
  
  [After Construction 2 product review]
  Customer: Yeah, I really like what you guys did for the graph here. This reminds me that we need to do a major overhaul to the input screen before this one. We also need some kind of batch processing for all these incoming data as well. As I look at it, I don’t think this program would make sense without these two things.
  PM: That might take a while to do. What do you guys think?
  Dev #1: My ballpark — 10 person days.
  Dev #2: Yeah sounds about right.
  PM: (pulls out the project plan) Let’s see, we are at the end of construction 2. We have construction 3, 4 and 5 to go. What if we move the profile page planned in Construction 4 to ‘nice to have’?
  Customer: No, I need that, too. I think we can push the form attachment later, though.
  PM: (move things in project plan). So, I’m putting in the two new things right here in construction 3, pushing everything down. Move attachment feature to nice to have for Construction 5. How does this sounds?
  Customer: Sounds good to me.

  As we can see, the PM still embrace changes. He just clearly presents what are the impact of changes to the deadline for the customer, so that they can make intelligent decision together.

• Architectural design early in the project. We can debate about this idea vs. the YAGNI principle influenced by XP. My opinion is that you should get the big obvious thing right because cost of changes is likely grow rapidly for these monsters. Fundamental changes to the system are not so easy to fix: “Can you do it like what you did having the central hub, but make it decentralized and secured?” — Good luck refactoring that! Might need another project just to make this kind of change. Early architectural decisions also help you identify the rigid parts from moving parts and help you contain those moving parts where chaos can safely happened.
• OpenUP assumes that some magic hands are doing the infrastructure work for you (how nice!). Truth is not a lot of people would have that luxery of having the project folder, templates, build servers set up. Even if we have it, somebody need to contact those support guys anyway. The developer role are pretty free during inception phase and would be ideal to take this job.
• Having roles give team members purposes. These tend to make meetings more effective as we consider different perspectives coming out from different roles (think six thinking hats…).
  
  Customer: Hey, what do you guys think if we need to track a record of each sales?
  Analyst: Is that only for the first time they pay or for all recurring payments as well? How do we track credit cards as well as purchase orders?
  Architect: We need to interface to those tracking vendors via web service. I’m afraid this might impact on the performance that we guarantee to have when doing the payment.
  PM: We might not be able to get to the UI changes we planned for the last iteration.
  Dev: Might be a nightmare to refactor all those billing logics!

Let’s Meet

Meetings are one of the inevitable things that mere mortals try to avoid (save those of the business types, right? — leave us to our codes and laptops). Truth is that to make meaningful software we need to collaborate. We cannot hope to roll out great software if developers do not talk to each other.

That’s why the beast called meeting was born to let developers have a place for focused conversation, solving problems and deliver good products. Wait — Did I say “focused conversation”? When was the last time I can called my meeting focused? Many “meetings” I have been looks rather like groups of people on chairs in each corner trying to fill the room with voices. I believe the reason why we all hate meetings so much is that we just listen to people talk and walk off with no value to ourselves whatsoever.

Back when I was studying about software engineering at CMU, can you guess what is the first thing they taught us about software development? Is that ground-breaking requirement engineering? Funky automatic verifications? Modelling of systems that can be proven deadlock free? … How about a fundamental collaboration process let us establish and perform other processes effectively? That’s right, ladies and gentleman, we are going to talk about effective meetings today. Not just your regular meeting, but an effective one. I secretly called a team that know how to meet a CMMI level 1.5 team (don’t even think about level 2 if you have not master your meetings).

I posted a generic meeting script here, both for you to use and for me to come back and lift off. Your needs may varies but all the key elements should be there.

Meeting Script

Roles

• Facilitator– Facilitate and set up meeting. Making sure everybody stays on topic
• Scribe — Taking meeting notes
• Time Keeper — Make sure each agenda item is on time
• Participants

Process

Before the meeting

1. The facilitator created an agenda of the meeting 48 hours before the meeting and send it to all participants. This includes
   1. Goal
   2. Agenda with estimates for each item

During the meeting

1. The facilitator presents the agenda to everybody
2. The facilitator opens each agenda topic from top to bottom
3. The scribe take notes at the meeting about what is said, especially action items that are committed.
4. Meeting keep keep track of time and warn facilitator when the time is almost up for each agenda item.
5. At the end of the meeting, the scribe reviews collected action items

After the meeting

1. participants evaluated each meeting agenda and address action items
2. Scribe sending out meeting minutes
3. Facilitator collects evaluation results

Meeting Templates

Agenda

Date	Day-of-week, Month Day, Year at time
Location	Building Room#
Duration	X hour
Goals	Described

• Item 1 ( 5 minutes )
• Item 2 ( 15 minutes )
• Item 3 ( 25 minutes )
• Review action items (5 minutes)

Meeting Minutes

Notes

• (Any format you like, bullet points works fine)
• (listen carefully to decisions and commitments)

Action Items

• (Say what it is and who is responsible for it)

Hints and Tips

• Do not, ever, make your facilitator the time keeper — The facilitator worries about content, the time keeper worries about time. The facilitator is very busy keeping people on topic already. We tried it, it does not work. Trust me.
• Always have an agenda – If you don’t have one, or cannot think of one. It is a sign that either there’s nothing to talk about, or you are not ready to talk about it. Better cancel the meeting to save everybody’s time.
• Have an agenda/notes template that we can quickly reuse
• For weekly meetings, it is a very good idea to follow up on action items generated last week.
• Keep review form simple. All you need is list out agenda items and have people said whether they satisfied with each of them
• Evaluations is the key to improve the meeting. If an agenda item is marked not useful to anybody, consider removing it from an agenda.
• It seems like Google shared a similar mindset of effective meeting! [ref]

The meeting script is adopted from the one I used in a practicum project with Aaron Fetterman and Geoffrey Giesel.

รู้ไว้มีฉันรักเธอ

เคยเจอมั๊ยครับ เพลงแบบนี้ เพลงแบบที่เราชอบทำนองมันมาก แต่เราไม่ค่อยชอบเนื้อร้องมันเท่าไหร่เลย

เพิ่งได้ฟังเพลงนี้ของโต๋ คิดว่าอยู่ในอัลบั้มใหม่นะ ตอนแรกฟังแล้วก็ไม่ค่อยรู้สึกประทับใจมาก แต่ลองๆ ฮัมเพลงตามดูแล้วกลับชอบแฮะ เหมือนว่าเพลงนี้มันมีจังหวะกับเมโลดี้ที่น่ารักดีนะ ฟังแล้วดูเหมือนว่าเรากำลังให้กำลังใจกับใครบางคนอยู่ ว่าเราจะอยู่เคียงข้างกับเค้าไปนะ ว่าชีวิตของเราจะไม่เดียวดายนะ ฟังแล้วรู้สึกอบอุ่นดีนะ

(download)

อันนี้ลองอัดวิดีโอด้วย จะได้เอาไปโพสในที่อื่นๆได้ด้วย อัดภาพกับเสียงแยกกันแล้วมารวมกันทีหลัง ก็เลยดูเหมือนไม่ค่อยตรงกันเท่าไหร่ (ไม่ได้ lipsync นะครับ )

It’s the Magic Moment

ช่วงนี้คงเป็น Magic Moment จริงๆ ไปที่ไหนๆ ก็เจอแต่คนขึ้นอัพเดทว่า Magic Moment. เพิ่งรับแอดเพื่อนอีกคนนึงคนนี้ชื่อเมล์ก็ยังลงท้ายว่า Magic Moment เลย ไปดูใน youtube อัพเดท ก็เจอเพลงนี้อีกแล้ว

เราก็กำลังหาเพลงแรกมาประเดิมโพสอยู่ด้วย ถือเป็นฤกษ์งามยามดี ก็เอาเพลง Magic Moment เลยละกัน … อยากเล่นเพลงนี้มานานแล้ว แบบ ลอยๆ ฝันๆ เหมือนความฝัน ก็มันคือชั่วโมงต้องมนต์นี่นา

ว่าแล้วก็ลุยเลยนะ เล่นเอาจากที่จำได้ ข้ามท่อนไหนไปบ้างก็ไม่ว่ากันนะครับ ^_^

(download)

Stop Making Excuses

I would like to make my first post with an open letter to software industry.

Dear Software Industry,

I would like to ask for your precious productive time to watch these video with me. This is a documentary about a design firm, IDEO, who were challenged to reinvent a shopping cart in 5 days. The video is split in 3 parts. For each one, I will mark point of interests for you.

• [2:55] Today we are going to talk about the process of product design.
• [3:43] The team kick off the project with a project charter
• [5:07] “We are expert on the process of design”. “Innovate by applying our process to it”.

• [0:30] I can see some form of requirements elicitation here, one that I could compare to Contextual design
• [2:48] You can see a brainstorming process with some rules to govern how it is conducted
• [4:30] Prioritization process follows to surface ideas that could be realized
• [5:20] Define need areas split the team to create prototypes of each one. The project manager helps setting goals for the team.

• [1:45] Review and Demo session
• [2:35] “Fail often in order to succeed sooner” == Release often and embrace change?
• [6:00] Using the design process in order to innovate

As you can see, Kelley mentioned in several occasions about how they are successful with the design process they have. Such things are not unique to IDEO or even to product design industry. I experienced similar mindset when I was trained by an advertisement agency during my internship. They explains their process to talk to customer to set a clear goal of an ad, work towards that goal, constantly review between ourselves and the client and make necessary adjustments.

Unlike you, software industry, these creative people do not view their process as an inhibitor of innovations, but a very key foundation to their success. They know that “innovation is real work that can and should be managed like any other corporate function. Success is more likely to result from the systematic pursuit of opportunities than from a flash of genius.” [ref]. In other words, they do believe that effective teamwork is only possible with the right amount of process.

In conclusion. I would like to kindly ask you to please stop making excuses…

• That we are so fundamentally different from other discipline such that simple principles of healthy collaboration and teamworks do not apply
• That software development are purely innovative business, therefore chaotic by nature and no kind of processes could help that. You can see that there are people out there, with their success and career based entirely on creative thinking, rely on these process for their workday to function smoothly.
• That software are late because customers changed their mind every second and rework are inevitable. Could that be, perhaps, because you did not do a very good job to let them understand what they need better?

Why don’t you start your very next workday with a new look on software processes. They are not there just to make life difficult. With the right amount of it, that might be your next secret sauce of ensuring effective teamwork and a key to deliver quality products on time.

Sincerely,
Me