Join Michael Lehman for an in-depth discussion in this video Exploring workflow integration and continuous builds, part of Learning Software Version Control.
Some Version Control systems, such as Microsoft's Team Foundation Server, have what's called Integrated Workflow Item Tracking. This means you can have your testers associate a bug with a particular check in. So a developer who does coding checks in the source code, a tester does some testing and finds a bug, so they log the bug. In this case, it's called creating a work item. That work item now represents a particular issue that's going on in the software. It goes back to the developer who fixes the bug, and then when they commit their change to the Source Code Control System, the work item is also associated with that particular commit message so that when the tester receives the notification that, that work item has been updated, they not only have the commit message that the developer created, they also know exactly which bug which they created is associated with that, so they can verify that the bug has in fact been fixed.
Here we can see an example. This is the Team Foundation Server Explorer inside Visual Studio, and here we have Work Items, and you can actually query for the Work Items that are associated with your particular user. Here we have a tester creating a New Work Item, and here the tester creates a new bug. In this case, Microsoft calls this an Issue, and they can fill in Priority and Status and a Description, add File Attachments, everything that a tester might want to be able to give to a developer to help them fix the bug.
Another development technique that is often used in team scenarios is something called continuous build systems. This means that every time you make a change to the Source Code, the product is rebuilt to verify that your changes are compatible with all the other changes being made to the system before the changeset is recorded permanently in the repository. So the developer makes changes to the Source Code and does the check in and the system then runs a build to verify that the changes that were checked in built cleanly. You can even make sure that the build system actually runs unit tests to make sure that they test cleanly before actually committing the changes to the repository.
I know that previous to this I said that the words check in and commit are equivalent, but in this particular scenario, the terms actually get split apart a little bit in order to be able to handle this multiphase committing process. So the developer does a check in and then the system does a build verification, and then once the build verification as passed, then the changes are actually committed to the repository. And here we can see in TFS a number of the different kinds of build quality gates that can be set up to determine when the code is actually committed.
As you start to use Version Control, consider how it can work with the other tools you are already using, such as build servers and bug tracking systems, and you can create a more powerful tool out of the combination of these tools.
- Comparing centralized vs. distributed systems
- Saving changes and tracking history
- Using revert or rollback
- Working with the GUI tools
- Using IDE and shell integration
- Installing different systems
- Creating a repository
- Tagging code
- Branching and merging code
- Selecting a software version control system that's right for you