Workflow for Systems Tasks

Overview

1. Create a new Tracker task.
2. Check out a working copy.
3. Create a new branch.
4. Make changes within the branch in your working copy.
5. Test your changes.
6. Fix problems discovered during testing.
7. Commit your changes to the branch.
8. Assign the task back to the person that created the task and send email to ask for review.
9. Review task with the person that created the task.
10. Merge changes from branch into trunk.

Creating Tracker Tasks

Problem Description

The most important part of creating a new task is writing a good problem description. A good problem description be "self contained"; i.e. it should include enough information for someone to start working on the task without having to ask additional questions or look up basic facts.

Feature Request

1. Start with a description of the problem that needs to be solved.
2. The next section should include a description of the change(s) or new functionality that may be needed to solve the problem.

Defect / Bug

1. Start with a description of the error, symptom(s) or feature that isn't working correctly.
2. The next section should describe the expected behavior; i.e. what would it do if it was working correctly?
3. Finally, the last section should include all of the information that someone else would need if they were trying to reproduce the problem. 

Categories

Feature Request

The Feature Request category is for new functionality which is not already included in the current application/OS/script/package, etc.

Defect / Bug

The Defect / Bug category is for problems with existing functionality in the current application/OS/script/package, etc. Before assigning the Defect / Bug category to a task, it is important to make sure that the application/OS/etc. is configured correctly. If the problem can be solved by configuring the application/OS/etc. correctly, it probably shouldn't be categorized as a defect or bug. An exception would be if you need to use a non-standard, or "unusual" configuration to work around the problem. In this case, there may still be a defect or bug that needs to be addressed.

Documentation / Procedures

The Documentation / Procedures category for topics or processes that need to be documented.

Priority

The Priority field is used to assign a priority to a task. If it's not clear which priority should be assigned to a task, state that in the problem description, and assign it the "Med" (medium) priority.

Assignment

If you're not able to complete a task by yourself, you may need to it to someone else. After assigning the task to someone else, send an email to let them know that a task has been assigned to them. You can do

Subversion

Checking Out a Working Copy

Check out a copy of the code, script, config file, etc. that you would like to make changes to.

Creating a Branch

Create a branch for your changes.

Making Changes

Switch to the branch that you created and begin making your changes.

Committing Your Changes

Please do not commit your changes directly to trunk! Instead, as you work, commit small sets of changes to the branch that you created. Each small set of changes should be logically related. This will make it easier to understand each change when looking backwards through version history. It will also make it easier to "cherry-pick" changes and apply them to other branches.

If you do not have a good understanding of all the changes that need to be made, it can be difficult to group them into small, logically related, sets that can be committed invidividually. It helps to have a plan before you start making changes, but sometimes it's still difficult. Instead of giving up and committing a huge blob of unrelated changes, there are a couple of other things to try.

Splitting Unrelated Changes Into Patches

The first approach is to try to split your unrelated changes up into a set of patches, with one set of related changes per patch.

1. Create a giant patch that contains all of your changes.
2. Revert all of the changes in your working copy of the branch.
3. Copy the patch from step #1, and rename it something that describes a set of related changes. It's useful to include a number in the name to keep track of the order that patches need to be applied in.
4. Edit this patch and remove changes that are not part of this set of related changes.
5. Try applying this patch to your working copy of the branch.
6. If the patch applies cleanly, make sure it does what you wanted it to.
7. Repeat steps #2-6 for any other sets of related changes in the giant patch created in step #1.

Start Over With A New Working Copy

The second approach is to start over with a new working copy. Use your existing working copy as a model for the changes that you would like to make to your new working copy. Try to come up with plan for organizing and grouping related changes before you start making changes to the new working copy.

Testing Your Changes

It is important to test small changes as you work instead of waiting until you're finished to test everything. It is much easier to test a small change and make sure that it is effective and doesn't cause any problems, than it is to test a large set of changes and try to figure out which specific change in the set is causing a problem.

Depending on what you're working on, you may be able to test your changes in a virtual machine on your computer. Some changes need to be tested on actual hardware. If so, they can be tested on terminals, tablets, print servers, or kitchen display systems in the lab. We also have a lab environment for virtual machines (VMs) on remote servers.

Please do not test your changes on customers' terminals, tablets, etc.! 

Code Review

Changes should be reviewed by more than one person before they are merged into trunk. When you're finished testing changes in your branch, assign the task to someone else so that they can review your work. The person reviewing your changes may suggest some improvements. This is intended to be constructive.

Merging Changes

Before changes can be deployed, they need to be merged into trunk. The person reviewing your changes may merge them into trunk.

Please do not merge changes into trunk without having someone else review them first!

References