Checking objects into VCS using Team Coding

Hello. I'm John Pocknell, Product Manager for Toad for Oracle, and welcome to this series Enabling Agile Database Development using Toad for Oracle. In Step 8, we're going to show you how you can use Team Coding to control the way in which code and other objects are checked back into source control. Basically, this is a system whereby you can employ some policies to control whether or not code gets checked into source control. And this is very useful leading into a continuous integration process, because you can have these policies set to control the quality levels before code is checked in. So why does Team Coding matter? Well, we had a previous video on Team Coding itself. It avoids the developer having to work with the files and check files out of source control. And it really simplifies the workflow, simplifies the task of checking an object out, checking it back into source control, without touching the files. Team Coding looks for any objects that are not synchronized with the corresponding files in source control, keeps the user informed. There are policies, which we'll look at in a second in a demo, which can be set during the check-in that look at code quality and functional correctness, and can deny the developer from checking a code or object in until the problem is fixed. This is important because, obviously, we want to limit coding best practice, because this can lead to poorly maintainable code in the future. Likewise, bugs. So we want to make sure that if we have unit tests set up, we run those unit tests as the code is checked to make sure that we haven't introduced any bugs into the code during any changes. And if we do this, then we're going to be on the way to following a full continuous integration process, which could be triggered by a check-in event, ensuring that these policies ensure the quality of the code is successful. All right, so I'll get into a demo. So here's my Toad user interface. I'm going to show you a couple of examples of how you can set these policies up. First of all, let me go to Team Coding. This would be something that was set up by a Team Coding administrator at either a global level or project level. Let me explain. So if, for example, you wanted to make sure that developers run unit tests that they have to find, as they check their code in, this is a global setting. So regardless of how many projects you have, once you have this set here, this Run Code Tester tests before check-in, that's going to run any unit tests that are found for that PL/SQL program. And if they all succeed then the code will be checked in. If any of those tests fail, the developer will be notified of this failure and the code will be prevented from being checked into source control. OK, so that's that one. The other one, which is to do with code quality, we're using coded analysis covered in a previous video, and this can be set at the project level. So we have three projects, each of which has a code analysis entry, two of which are disabled. This one I have enabled, so I just show you the settings. I checked the box to integrate it with code analysis, but make sure that as developers check code in, if that code is belonging to this project called Demo_Project, then it will follow the criteria in this window. And if it fails any of the criteria, then the code will not be checked into source control. So I'm checking for things like rules violations, based on my rules template. We talked about that before in code analysis. I'm using all rules. There aren't any other rule sets that you can have to find. I'm checking for syntax errors. I'm particularly checking for the quality of the code before and after check-out. So if the code quality is lower than it was, in other words, the quality metrics are lower than they were when the developer checked the code out, then I'll stop the check-in. And then the last one is I'm storing the check-in metrics on the Toad server, Toad Intelligence Central server as well, so I can see what's going on there as well through the web report. OK? So that's all set up. How does it actually work in practice? So here's an example here of a function. It is already checked out, as you can see at the bottom. And I'm going to deliberately make the quality of this code worse than it was before just by removing a couple of values. Here you can see this coding violates a couple of coding violations here. And I'm just going to go ahead and check that in. OK. There's the check-in box. I can Force Revision level and so forth. Click OK. And what will happen is, you'll get this pop-up window. So this pop-up window is basically saying you got a validation error, check-in is prohibited, and here's why. In this particular case, the Toad Code Rating metric, which is an amalgam of some of the SEI metrics, Software Engineer Institute metrics, that we have is fine. It passed on that level. But there were too many syntax errors, and therefore the code, the check-in button, is unable. Now that's optional. If you want to have developers override that-- have this notification, you can do that in this particular case. That's been denied, and therefore the only choice the developer has is to correct these issues in here like so. Put some values in here like this. And I'll recompile it and then check it in and hopefully you'll go ahead and check it in, which it has. So this states that it has changed from checked out to available. So that's basically forcing a code review,