Access objects from VCS using Team Coding

Hello, my name's John Pocknell, Toad for Oracle product manager, and welcome to this multi-part series on enabling agile database development using Toad for Oracle. In step 2, we're going to talk about how we access objects from version control using Team Coding. Step 1 covered the initial set-up routine coding and the integration with a back-end version control system. So why is this important? Well, using Team Coding with version control ensures that only one version of an object is modified at a time to ensure its integrity and to ensure control of the correct version that is eventually deployed into production. Using Team Coding enables developers to work directly on a database object, without having to access the file in source control. Team Coding constantly reconciles any changes that are made to database objects with the corresponding files in source control, and creates a new version as the editing session is completed. Team Coding keeps the database object and the corresponding file in sync at all times. Any out-of-sync condition that is detected-- perhaps because a developer's accessed a program from source control without using Toad-- is flagged to the Toad user at check-out time, enabling the developer using Toad to merge both changes, if necessary, into a single version and check that version into source control. Optional policies in Team Coding facilitate PL/SQL regression testing and code reviews at check-in time. This is important if you are following agile methodology, and perhaps you have a continuous integration server with automated build that is triggered by a check-in process. So let's get into a demo of how we actually use Team Coding. So here I am inside of Toad. I have Team Coding set up. That was carried out in the first video. You can see on my left hand side I'm a Team Coding manager. I have my team projects listed here. Let's go back into the Team Coding Configuration for a second as well. So now that Team Coding is set up, it means that users using Toad can access the code that's in version control using the Team Coding interface. So there's some settings that you might want to have at the user level, such as whether or not to force a new revision when the code is checked in, whether you want to add comments when the code is checked back in, and there's also some settings at the team level which would override the user settings. For example, if an out-of-sync condition exists, do you want to force the database version to be the up-to-date version, or the VCS version, or do you want to prompt the user and have them decide which course of action to take? Also, at the team setting, if you want to have a unit test, all the unit tests with a piece of code run before the code is checked in, that setting is there. At the team projects level, if you want to have a code review done at the point code is checked in, you can do that in here. And this is done at the project level, because obviously you might have different coding standards for different projects. So that's some of the other configuration options. So let's see how it works in practice. So I can see from my left hand side here that I've got code in this schema, quest dev, including these functions in version control. So I'm a developer and I want to make a change to this function. I simply double click it to open it into the editor, and what's happening at the back end is it's going to check the file from source control. So I sign on to my version control provider. I'm using Subversion in this particular example. And you can see in the notification window at the bottom here, I'm getting a notification that this code is checked out. And if you look on the left hand side in my Team Coding Manager, you can see that the green dot is now changed to a different symbol to indicate this code is now checked out. To confirm whether it's also checked out from the version control system, and not just simply checked out from Team Coding, if I go over to VCS now and look at what's going inside of my dev project, here's a quest dev schema. Check the function list, you can see that it also is indicating that the code is checked out, which means that no other developer can check that code out or make changes to it until the initial developer has completed the work and checked it back in again. So when the changes are being made to the code-- I'll just make a minor change in here, just change this word "parts" to "stock" and recompile-- compiling means that the database version of this object is now updated in the schema. And if I close this tab down, it instantly pulls up the check-in objects dialog to say, well, you're going to check this object into source control. Here's the project into which it will be checked in. Do you want to add any comments? Like so. Force a revision. And click OK. And that code is then checked in. So let's examine what actually has happened here. So if I go back to my team projects here, and go to the project dev project, and look at this function. If I right click this function and show properties, then I can see what's actually going on with this piece of code. So here's all the information pulled from the Team Coding Repository, including any comments, what its current status is, what the VCS working file is, any code analysis statistics, if I'd run them, and then down here I've got two different revision levels. And if I multi-select these two different revision levels and compare content, then I'll get a look to see how they're different. So you can see on the left hand side version 368, which is the latest version, is using the word "stock," whereas the previous version was using the word "parts." OK. So that's at the code level. So what I can also do is have a look-see across all of my code. So if I go to Team Coding, Show Team Coding Objects, this will give me a report of all of the code that's registered in my Team Coding Repository. And if I expand this out here with my development project, I could look at the same sort of information. So if I click on this function here, you can see now I've got a history of all the transactions that happened to this particular object, both at check-in and check-out. Lots of information in there. So what I'll do now is just show what happens if there is an out-of-sync condition, because this is worth noting as well, because what Team Coding is designed to do is to preserve the integrity of the code under all eventualities. So I'm in a different schema now, and I'm selecting actually a more mature version of this code. I'm going to check this out the same way. So I just double click it, just to open it. And you can see what's happened here is that it's coming up with a different dialog that says there are two different versions. The database version and the version control system version are different. Now, that might happen if you have some people not using Toad, and therefore accessing the code directly from source control. Team Coding doesn't have a record of that transaction. And so when a user accesses the same program using Toad and using Team Coding, it's going to detect a difference. So if I press View Differences, I can see the two different versions of the code side by side here. OK, and it gets highlighted there in the yellow line there. So yellow line is modifications. Red lines indicate deletions. Green lines indicate added. And resolutions in blue. And so what I can do here is if I wanted to, this obviously wouldn't make sense to merge these two. But if you had changes that were done by somebody else to a different part of the code together with the changes that you'd made as a developer to a different section of the code, you could view both sides, and actually you might decide, well, I actually want to merge them both together. And so what we can do is you can open the Merge window. So if I press this button here and they will merge. Then what you'll get at the bottom screen is the effect of merging both the change in the left panel with the right panel. And then what you can do then is you could save those as a file, say merge source, and then check that file into your version control system, and that would represent a merging of those two different sets of changes into one change. So that's a quick summary of how to use Team Coding to check code out. Thank you for listening.