Hudson Logo

Hudson Core Release and Development Processes

Index

  1. Introduction
  2. Release Cycle
  3. Release Planning
  4. Quality Assurance Testing
  5. Working with Hudson Source
  6. Hudson Website Management

1. Introduction

This document outlines various processes around the day to day and release to release development of Hudson. It does not cover the actual process of becoming a committer on Hudson (this is covered by the Hudson Software Process) or the mechanics of building Hudson from source which is covered in the Wiki. Furthermore this document only covers the processes relating to the Hudson core and does not apply to non-core plugins which may choose to adopt the same process if they wish or may use some totally different process that suits the style of the relevant contributors.

The development processes assume that the following logical roles exist within the Hudson community universe, an individual may hold one or several of these roles:

Commenting on this Process

Any comments you have relating to this process can be recorded and tracked in the Hudson Wiki. When commenting, please be sure to refer to the reference number of the section or paragraph that you have the comment on.
Older versions of this document are archived for inspection in the WWW source control area

2. Release Cycle

The proposed Hudson release plan is that we should aim to release a new version of Hudson on a regular cycle of 5 weeks. This schedule will consist of a 4 week development sprint followed by a week of feature QA followed by a further week of integration and install QA.

We have attempted to capture the flow of this process in the following diagram, as you can see the individual iterations overlap by 1 week to provide the 5 week cycle.

Visio diagram of Hudson Release Process
Figure 1: The Hudson Release Process

Much of what is shown in this release process will be automated in the long term, however at this time activities such as changelog updates and staging of downloads are manual tasks to be handled by the various roles as defined within the Hudson community.

3. Release Planning

Hudson release planning occurs at the start of each new release phase and runs parallel to the BugFixing phase of the previous release.  During that week we will consider all issues in Jira based on their priority and vote count.  In scope, this will include both bug fixes and enhancements. Once candidate issues are identified the following will happen:

  1. The JIRA Fix Version/s field will be set for the issue to that release. This adds the issue to the backlog for that release.  
  2. As developers become available or identify items they wish to work on, they will assign themselves as owners. 
  3. We will have a checkpoint during the 2 week mark of the cycle for the release to gauge the size of the backlog to determine if we’re on track or if we need to add/remove backlog items. 
  4. At the final 4 week development mark, we will push any uncompleted items to the next release automatically.  If users want specific issues completed, they are encouraged to set the priority and vote for those issues to ensure they get the proper attention.

4. QA Testing

The proposed cycle includes a provision for various types of testing:


Prior to every check in (responsibility of the individual developer):

  1. Unit Testing

Nightly (automated):

  1. Unit Testing
  2. Code Coverage

Release Testing (Automated / QA initiated):

  1. Upgrade Tests
  2. Regression tests
  3. Functional tests
  4. O/S Install Testing

To test and validate Hudson, we will start to classify the plug-ins using a tiered system. This will consist of 3 levels of plug-ins and The qualification of plug-in falling into this level is up to the Hudson committee and strictly governed. The definition of the tiers are:

  1. Tier 1: These plug-ins are critical to the functionality of Hudson. They will be verified to work on each release of Hudson by QA.
  2. Tier 2: These plug-ins represent the top 90% (approximately) of popular Hudson plug-ins. They will have some level of testing to ensure they work and can be installed but are not necessarily validated on every Hudson build. They represent the most popular and useful plug-ins.
    To qualify at Tier 2 a plugin must:
    1. Have an owner identified
    2. Have some level of tests defined, preferably automated
    3. Deemed important and one of the heavily used components by the Hudson community
  3. Tier 3: All other plug-ins default to tier 3. These are not actively tested by Hudson QA though plug-in owners are encouraged to provide automated test cases that can be run for each build to Hudson infrastructure to be run.

The full list of plug-ins and their associated tier level is defined here.

5. Working with Hudson Source

The process here assumes that the developer is already a Husdon Core committer (as discussed in the Software Process) and has already signed the OCA.

The main code repository for Hudson Core is at GitHub (https://github.com/hudson). When a developer wants to work on the source code either to implement a new feature or create a patch for an existing issue they should follow the following process:

  1. Create a GIT Fork of the repository using the the GIT Clone command.
  2. Work on this local fork committing as often as required.
  3. Before merging back into the Hudson Core you should pull all changes from Hudson Core into your fork using the GIT pull command and resolve all of the merge conflicts at this stage.
  4. Finally merge your fork back into Hudson Core using GIT push
  5. Throw away your private fork

6. Hudson Website Management

Unlike Hudson core, the hudson website artifacts are managed in subversion for ease of interoperability with content management tools such as Dreamweaver. During normal operation the website will operate on a continuous release cycle with changes made directly on the trunk and published immediately (or at least nightly). The one exception to this will be in Week 6 of the main development release cycle when we will branch the website in order to prepare the correct links for the new downloads and change logs.

Upon successfully release this release branch will be merged back into the mainline.

Comments or feedback? Head over to the wiki.

$LastChangedDate: 2011-03-14 18:15:29 +0000 (Mon, 14 Mar 2011) $