Hello. My name is John Pocknell, Toad for Oracle product manager. And welcome to this series on enabling agile database development using Toad for Oracle. In Step 9, we're going to show you how you can create and publish workflow automations using Toad and position them in such a way that they can be used by a continuous integration process.
So why does automation matter? Well, if you're moving to an agile database workflow, automation really is essential to help you shortening your database development release cycles. Things that we've talked about in previous videos, like unit tests and code reviews, really need to be automated in order to help short that release cycle. Automated workflows can also be reused once they are created and can help drive up standards and consistency.
In order for development tasks, such as PL/SQL unit tests and code reviews, to become part of an agile workflow, we first need to encapsulate them as automation artifacts in Toad. Once these artifacts are published onto Toad Intelligence Central server, they can be called as part of a continuous integration automated build process, such as you would find on Jenkins, Hudson, Bamboo or something similar.
So let's get into a demo and actually show you how this works in practice. And we'll be touching on some things that we covered in previous videos. We're kind of putting all this together now.
So here we will see automation designer, which can be accessed through this button here on the toolbar. And in automation designer, as we talked about before, this is divided up into different functional groups. In the DB Miscellaneous group, we're particularly using the code tester action and the code analysis action.
And I've got a couple of already created here. And I'm going to look at the properties of each one to show you how you can populate them with code. So by right clicking and examining Properties, you can see how each one is made up. They're very similar in their approach.
First, of all code analysis-- you need to specify an output directory to save the files locally, because we haven't published anything at this point. So that's just a local copy of the file-- and in the sorts of reports you want. In my case, I'm just going for an HTML report to save the results into. I could use Excel and other formats as well.
And then the items-to-process list-- the items-to-process list is the code that you want to have reviewed as part of an automated build. And that's for you to decide.
Now, so that's the code. What standard are we doing a code review to? Well, that's determined up here.
So this drop-down here displays all of the rule sets, which, remember, are containers for rules. So these contain the rules against which all of the code in the bottom list will be reviewed against. And then if any violations flag up, they will be reported on.
The difference here and here with this automation is, as we generate results, we want to save the results as well to Toad Intelligence Central, so that they can be reviewed through the code quality dashboard on the web server part.
So how do we populate the list below? Well, you can either load objects from the database, and they're grouped by object type-- we could just say load all objects, and it will search for objects in the schema that you're connected as-- that is, it's default owner. Or, you can open a file from the file system. Either way, you'll add a list of code at the bottom here, for which you want to run a review. So that is that.
And you can perform a test run. It's advisable actually. Do a test run on the Toad client to establish that you don't have any issues. Because, you know, if you're going to position this in a place where it becomes part of an automated build, you just want to check that that build is going to succeed. So, doing a test run here, in this particular case-- this has worked fine.
Next, look at the code tester action. Right click Properties. Slightly different here-- again, you've got output files. You can specify an output file locally. Alternative-- you can check this box, which is publish the results onto Toad Intelligence Central.
The list below is a list of code that has unit test defined for it. So what we're doing is, we're running all the unit tests for each of the objects specified below. You can add additional objects by using the Plus button here. And that will present you with a list of everything that it finds in the code tester repository. Now, this could be a long list, so you can sort this list by object owner or by object name and then make selections on the left hand side here.
You can also select test suite. This might be advisable too. So, if you actually want to combine multiple tests into a test suite, like a grouping function, in such a way that that would constitute what you want tested as part of the build, so each suite would represent build, you can do that first, ahead of time, inside a code tester.
And then-- what you're seeing here is, then, a suite. A suite contains many unit tests. And so, you can select a suite.
You can then, again, remove-- so, there's a minus button here to remove anything from this list.
Once you're done, you can do a test run, and this will run all of the unit tests in this list, for all of the programs in the list, and let you know whether you successfully completed those tests or whether any of those tests fail. Again, you want to want to check that first before you publish the automation onto Toad Intelligence Central. So, you can see both have completed.