Developing

Edit online

This task describes how to work on a development task and share your changes with the development team.

This graphic is a workflow diagram that shows the steps that make up the develop task. Click here to get information about completing plan items Click here to get information about elaborating plan items Click here to get information about detailing requirements Click here to get information about building Click here to get information about testing Click here to get information about reviewing development tasks Click here to get information about updating source files Click here to get information about writing unit tests Click here to get information about checking in changes Click here to get information about building and testing locally Click here to get information about delivering changes

As a developer, you find the work items that are assigned to you for the iteration and update source files as needed to complete the work items. As you make changes, you check in your files to ensure that your changes are not lost if your computer suffers a hardware failure. When you finish working on a work item, run a personal build, and test the changes locally. Fix problems that you discover. When the build succeeds without errors and your unit tests pass, share your changes with the team by delivering them to the stream.

Before you begin

Before you start working on development tasks, the development lead must create an iteration plan, assign plan items to the iteration, and decompose the items into finer-grained development tasks. The requirements analyst must then specify detailed requirements for plan items and, where necessary, development tasks.

Step 1: Review development ask

The first step is to find the work that is assigned to you and familiarize yourself with the requirements behind those work items.
  1. Find the work items that are assigned to you for the current iteration. You can find your work items several ways. You can view them in the iteration plan, in your personal or team dashboard, or in the Current Work section of your My Work view.
  2. Open one of your work items and review the description. On the Links tab, navigate to linked requirements to learn details. Navigate to the parent plan item to see how the development task fits into the larger feature.

Supporting tasks:

Step 2: Update source files

After you research the work item, you are ready to create and modify source files. To work on files and share them with your team, you must set up your source control environment.
  1. Create a repository workspace for the stream that your team uses. A repository workspace is your personal work area within the repository, and it maps to a directory, or sandbox, on your computer. In the New Repository Workspace wizard, select the components to load into your repository workspace and sandbox.
  2. In the IBM® Engineering Workflow Management client for Eclipse IDE or Engineering Workflow Management client for Microsoft Visual Studio IDE, access the files that to modify.
  3. Change the status of the work item to a state such as In Progress to indicate that you have started working on it.

Supporting tasks:

Step 3: Write unit tests

After you finish coding your changes, create or update unit tests and associate them with the new or modified classes and methods.

Step 4: Check in changes

After you save your changes, check them in. Checking in your changes copies them from your local sandbox to your repository workspace and ensures that your work will not be lost if your computer suffers a hardware failure. It is good practice to check in your changes frequently.

Supporting tasks:

Step 5: Build and test locally

Before you share your changes with the team, run a local build and check for compilation errors and unit test failures. If you discover errors, fix them, check in your changes, and run another local build. Ensure that you have a clean build before you deliver your changes to the stream.
  1. Request a personal build. A personal build uses the files in your repository workspace rather than the files in the stream. A personal build sends alerts only to you, not to other team members, and does not affect the status of the build definition.
  2. When the build finishes, review the results. Check for compilation errors. If your release engineer has configured the build definition to publish the results of unit tests, such as JUnit tests, examine the unit test results on the Tests or JUnit tab of the build results.
Supporting tasks:

Step 6: Deliver changes

To share your changes with the team, deliver them from your repository workspace to the stream. The stream is the shared work area for the team. After you deliver changes, team members accept them into their repository workspaces.
  1. Before you deliver a change set, associate it with the appropriate work item. Work items and change sets contain links to each other; with these links, you and other team members can quickly see all the changes that are made to implement a task.
  2. Change the status of the work item to a state such as Resolved or Implemented to indicate that you have finished working on it.
  3. Deliver the change set to the stream.
Supporting tasks:

Results

You have made changes that are required to implement a development task, tested your changes in a personal build, and shared your changes with the development team.

What to do next

Have the release engineer run a team build that includes the latest changes that have been delivered to the stream.