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.
09:35