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.
Common Tasks
Task |
Supporting Content |
|---|---|
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. |
Related Scenarios
Performing Common Development Tasks
When you complete a development task, you have performed all of the necessary steps required by your team's process or methodology.Identifying Code Change Impact on Tests
Before you check in your changes and resolve associated work items, you should run tests to verify the parts of your application that are affected by your code changes. You can use the Test Impact Analysis features of Visual Studio Premium and Visual Studio Ultimate to see which tests must be run.Verifying Code by Using Unit Tests
You should run existing tests, and you might want to author additional tests, to verify the behavior of your application. If your application uses one or more databases, you might want to generate realistic test data to use for those tests.Analyzing Application Quality by Using Code Analysis Tools
You might want to analyze your code to check for common design issues that could cause problems for users of your application.Managing Development Schedules and Work
After you have checked in your changes and resolved your work items, you might want to review the development schedule for the current iteration. You can discover whether you are on schedule. If the task took longer than you expected, you can discover which team members had dependencies on your work so you can discuss the effects of the delay.