Team Foundation Server Plug-in for Eclipse
You can use Team Explorer Everywhere to improve the predictability of your development processes. Team Explorer Everywhere includes both the Team Foundation Server plug-in for Eclipse and the Cross-platform Command-Line Client for Team Foundation Server. You can use the work item tracking features to capture what is important to your customers, and track your project's progress. This enables you to enact processes and monitor their quality to help your team turn customer requirements into working software. You can manage your source code and project artifacts by using Team Foundation version control. By using version control, you reduce risk and help improve the quality of your application. You can build your application by using the integrated build system so that your team can ensure that quality gates are met and can see what requirements have been fulfilled in each build.
Using Team Explorer Everywhere for Iterative Development
Task |
Supporting Content |
|---|---|
Getting started: Before you can use the features of the Team Foundation Server plug-in for Eclipse, you must first establish a connection to an instance of Visual Studio Team Foundation Server. |
|
Set up the local development environment: In most team development environments, you must obtain access to the correct version of the source code files. You then update your local computer with the source files for the parts of your application that you must update. |
|
Make code changes to accomplish a task or fix a bug: During a development cycle, you spend most of your time making code changes. This process includes selecting a task or bug, checking out the required files, modifying the code, and then verifying that your changes are correct before you check them in. This task includes making changes to both application code and database code. |
|
Create and request builds: You can use the integrated build system to perform automated builds on a scheduled basis or on demand. |
|
Define quality gates: You can specify check-in policies to help protect the quality of the source files that are checked into version control. |
|
Troubleshooting: If you encounter issues when you use Team Explorer Everywhere, you can find information about common issues and their resolutions. |
Perform Iterative Development Tasks
You perform a set of common steps for each development task. Depending on the process used by your team, you might perform these tasks in a different order. For example, you might define your tests before you make code changes.
After you have identified a coding task and you have updated your local development computer with the correct version of the source code, you can make the necessary changes to your code. However, changing the code is only the first step, because you typically must test your changes. After you have verified the behavior of your application, you can complete your development task and move on to the next.
Task |
Supporting Content |
|---|---|
Identify work to be performed: Your work typically consists of one or more coding tasks that must be performed, or one or more bugs that must be resolved. You retrieve the highest-priority items that are assigned to you from the work item tracking database. You might also review the overall schedule for the current iteration to verify that you can complete your tasks in the expected timeframe. You should also review the dependencies that other team members might have on your tasks, to avoid blocking progress. If your team has full-time testers, you should discuss the work with the tester responsible for the affected feature areas so that the tester can begin any test planning that is required. |
|
Prepare your development environment: After you have identified the work that you must perform, you might have to update your development environment so that you have the required source code. If you are fixing a bug in a released or deployed version of the application, you might update your environment to have a specific version of the sources instead of the latest version. If you are working with databases, you might also want to configure a local development server. |
|
Identify the cause of code defects: Often, the first step that you take when you must fix a bug is to use the debugger to identify the cause of the issue. If the issue was recently introduced, you might check the historical data for the source files that contain the error to determine when and by whom the issue was introduced. In some situations, you might want to roll back the original change and consider a different code change. |
|
Make code changes: You identify what changes have to be made, you make one or more code changes, you test those changes, and you verify that your changes meet the coding standards of your team. |
|
Complete the work: When you believe that your code changes are ready, you often review them with one or more peers, perform a final full build, and run check in tests. After you have checked in your changes and resolved any merge conflicts, you resolve any related tasks, bugs, and other work items. |
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.
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 shelveset that contains your changes. Other team members can examine the contents of the shelveset. 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 and run related tests: Often, when you are making code changes, you build only those parts of the application 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. On many teams, you must also 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 changes, 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. If you are changing code that is protected by a gated check-in build, a shelveset will be created and your pending changes must build successfully before they will be checked in. |
|
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 changeset 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. |