Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
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.
Get unlimited access to all courses for just $25/month.Become a member
61 Video lessons · 105523 Viewers
56 Video lessons · 117178 Viewers
71 Video lessons · 86413 Viewers
131 Video lessons · 41310 Viewers
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.