Completing Development Tasks
When you have completed the implementation and testing of a code change to address a task, a bug, or another work item, you typically perform several additional tasks. In a team environment, you often ask one or more members of your development team to review your code. You should also perform a final full build of the application.
You might have a set of check-in tests that must be passed before you can check in the code. After all criteria have been satisfied, you can check in the pending code changes, resolving any merge conflicts.
Only when all the steps that are required have been completed do you resolve the corresponding tasks, bugs, or other work items.
Have the code reviewed by your peers: In many team development environments, you must have code changes reviewed by one or more peers before you can check in those changes. You should consider having one of your peers review any complex code even if this step is not required by your team.
To facilitate a code review, you might prepare a shelve set that contains your changes. Other team members can examine the contents of the shelve set. Additionally, the changes are saved in version control so that you can work on other tasks, and so that your changes are not at risk if something unexpected happens to your development environment.
Perform a final full build: Often, when you are making code changes, you build only those components that you are changing. In a team environment, you should consider building the whole application before you check in the changes. On some teams, you can submit check-ins to a computer that runs continuous builds.
Run all check-in tests: On many teams, you must run a subset of the application tests known as check-in tests. These tests verify that you have not broken behavior of the application in areas other than those that you modified directly.
Check in all changes: After you have verified your changes, you must check them in to version control to make them available to the team. By checking in your change, you also cause them to appear in the next full product build. You can also revert pending changes if, for example, they posed too much risk in the current stage of a product cycle.
Resolve tasks, bugs, and other work items: After you have checked in the changes, you can resolve the related tasks, bugs, or other work items that are associated with the changes. You typically associate the change set that contained the changes with the work item; if you do this, and then the bug recurs later, it will be easy to find the set of related changes. You should include enough information in the work item comments that other readers can understand what change was made and why. Also, you might consider applying a label so that you can refer back to this version of your source code.
After you complete a work item, you might have to adjust the development schedule if that item took significantly more or less time than expected.
Provide design feedback: When you make a code change, you might have to change elements of the application's design or architecture. If you change the design, you should update any architectural or design documents (this includes models) to reflect the changes. In addition, if you corrected a flaw, you might want to provide guidance to other team members about the nature of the flaw and instruct them about how to avoid it in the future.