I'm going to have Vamshi tell his story about how they got into DevOps and specifically the challenges they had around bringing in Oracle database change management operations into a DevOps pipeline. So his company had been using DevOps for a while, but this specific challenge was unique really and had some pretty interesting challenges. How may of you are looking at bringing database change management operations of your DevOps pipeline? Just a show of hands.
All right, so this should be an interesting story for you to listen to if this is something that your moving forward with. So Vamshi, just to start with, just talk a bit about your role in all of this. What part do you play?
So I'm the manager for the DevOps infrastructure. So I was database manager. And I was given the lead role of starting DevOps for database. So we didn't know how we could integrate the DevOps for database since database was so unique because always data gets changed and integrity of data and then integrating with the release management with data was always a challenge. So I was brought in initially to see how we can integrate the database or database release management and follow the CI/CD process of DevOps, and then do it successfully, OK.
So because the development-- developers were going at a great speed at adopting DevOps. But the Achilles heel was always the database changes. So database was not able to match up to the application DevOps. So that's where I was brought in to lead that project.
So what is driving all of this? I guess this is not something IT would just choose to do, right? I mean, where did this all come from? Obviously, the business wanted their changes to be faster, cheaper. Developers wanted to accelerate their changes and automate the changes and integrate the database changes with application changes and move forward. And infrastructure wanted to provision the data, provision the containerized everything, and do the changes faster.
And DBA team wanted to have the integrity of the database. So that's where the complexity arise because though there were three different groups wanted to move forward. The database team was unsure of the integrity of the data. If we do move that forward, there's PII data. There's several kinds of data in the large data sets. It was not as easy as migrating a code. Database as itself is a different animal to deal with during this whole change process.
So let's talk about some of the challenges there since you mentioned DBAs and developers because historically with database change management, it's a very siloed type of operation, right? Developers do their thing. Deviates do their thing. So talk about first of all on the developer side, what specific challenges did you database developers have in trying to move this process forward?
Yeah, so the challenges with developers was the code that we had, especially the database code, PL/SQL, was very legacy. There was no uni testing. There was no-- the code was written 20 years ago by different-- used different best practices. Yeah, so you're laughing, so you kind of know what I'm talking about. So that was a challenge.
We didn't have the developers who wrote the code but not available. It was so hard for us to range any of that, have something, you know, yeah, we wanted to move to DevOps. We wanted to change to have the quality in the code. We wanted to move everything to best practices.
But there were not many tools available at that time to be able to do it. And our quality team wanted to reduce the technical debt. So that was also a challenge. How do you reduce the technical-- there's 20,000 lines of code, 10,000 lines of code, immense logic in it. So it was very difficult to do that.
And how important is using source control in all of this? Are developers already using source control system?
So developers were not using the source control, especially when PL/SQL is residing in the database and refreshes are happening constantly, right? So we never knew where the code was in which environment. The only way we could do the refresh was get the whole production into one of this environment. Then run the PII. So it was very difficult.
There was no baseline at all for our code. So that's why to do any development on which baseline do we do, right? So that was-- our test cases were all absolute because changes were happening all over the place. There was no control on the changes. So that was one of the challenge.
So what about-- talk about your DBA operations. How did the-- where does the DBA fit in this? Were you getting resistance by the DBAs in all of this, or did they embrace it?
How did it work? So DBAs-- they're more focused on the integrity of the code, their relationships, to make sure that there's no changes won't impact the performance of the application. So there are more having control on all the changes. So they would not move as fast as the developers want to move because ultimately, any resulting change would impact the application and the data integrity. And with the cost base optimizer in Oracle, you know what's going to happen if the table or column is added, not tested. So that's why database DBA team was very resistant for this fast pace changes.
All right, so OK, that sounds great. In terms of tooling, what sort of tooling did you look at? And how did you make a final judgment? What process did you go through to look at what was out there and assess its capabilities against what your needs were?
So DevOps today, right, there are so many tools in the market. They do one piece at a time, right? So for us to pick a set of tools where the tools are very-- our developers are familiar with the tools. That was a key for us to pick the tools.
So we did several POCs before moving to pilot. So that the-- we wanted to make sure that the tools were familiar. The tools did not have a huge learning curve. And I know that there is no silver bullet, a one, two doing end.
So it was always picking maximum features and where they fit in. So it's-- because the tools were so many, we wanted to make sure that they integrated well. And then we wanted to make sure that's less a learning curve for them. So for that, POC training, you know, that was very key for us to get and a dedicated team.
So what Quest tools did you arrive at in helping you? Because you're already using Toad for Oracle, right? What other tools did you look at?
So Toad Quest the new versions of Toad, if you are using Toad you know, there's unit testing in tool in Toad, which may have the latest version. They had the functionality. But the developers were not using the Toad. So we went to Quest and got the their Toad world.
There are a lot of training sessions. And we had contact with John, spent hours training our developers how to create a unit test. So this [INAUDIBLE] learning. It's so easy to create a unit test with the new version of Toad. There are a few clicks.
So compared to what they had to do with JUnit, they have to write lines of code, you know, so that helped us. With the unit test, the code internally, Toad writes those code for you. And then [INAUDIBLE]. So if you are not happy with the code, you want to do modifications per unit test, you can go easily and edit it. So that's an eye opener for that.
We can really do that unit test that easy. So we made it mandatory that every code which goes into check in, you need to have a unit test. And Toad actually integrates with version control. So these test cases are already checked into the version control. So that test case, you can not only run for your unit test. You can promote it to the higher SDLC environments.
So how [INAUDIBLE] how about you build automation process? How did you having created these unit tests, and you've got your code check into source control. How do you bring that together with your build automation process?
So the Quest has the DevOps tool kit, which integrates with-- they have a plug-in into Jenkins So the orchestration process is so easy for us to take over. And not only that there are other other features of the new version of code like code analysis, where it actually scans while the developers are doing the development. It actually scans through and gives you of whether your code follows the best practices, whether your code, you know, how does it scale with the quality of the code.
So it gives you an HTML report as to how to rate your code as so that we can put some thresholds if it is false 85% or 95%. Otherwise, it won't allow you to check in. So that was very key for us to measure. Technically it would go and say you know what, this code doesn't match this preferences. So that was very key.
And then there was a benchmark factor in the other one where the performance testing was very key because we would wait for the last piece of the SDLC to do actually performance test. But the code has the Benchmark Factory, which while doing the unit testing, you can actually do your performance test on that unit of code. So that helped us resolve the performance issues while the developer was developing rather than there at the last end of your SDL cycle.
OK, great. Just one other question. So what stage are you currently at then? So you did approve POC. Are you using any of this in production yet?
So we just finished up POC. And we are doing our pilots with four applications. It's in production right now. So we are very happy with the way the adoption went.
And now we're going to scale it slowly. So DevOps, one key thing is crawl before you walk. Walk before you run. So that was a key rather than flip a switch and everything goes to DevOps.
And what's the expectation for you in terms of release cycles? What are you looking to get down to now for your release cycles?
Like every release cycle was eight weeks, which was not acceptable. So now we wanted to cut down to two weeks with cycles with the spring and [INAUDIBLE] that's our goal to have a release cycle that fast. Maybe faster once it matures.
Great, so one final question I think for the audience is, you know, sort of what advice would you-- what recommendations-- if any of the folks in the audience here are looking at how to bring their database change right into DevOps, what advice would you have for them?
I think picking up the right tools is very key and having a dedicated team across from POC across the pilot and production. So that was one more piece. And then make your learning curves as lower as possible. If you're familiar with certain skills, make sure that you use those skills. So that cultural barrier of the cost of the tools will be reduced. So that would be my suggestion.
All right, thanks very much. So we got some resources for you. We've got a DevOps solutions page on Quest.com. So we got Quest.com/database/solutions, you'll see a page there that talks about some of the products that we just talked about here, plus Foglight, which is our monitoring. So you can monitor DevOps pipeline, SharePlex to replicate changes out to other environments. So take a look at that.
And there's lots of on Demand webcast to talk about database DevOps. So plenty of place to go to. I want to thank Vamshi for taking the time to come along and talk to because it was an interesting story. I hope you found it interesting.
And if you want to stop by and ask Vamshi any questions one-to-one, feel free to do that. And we've got some demo stations on the other side of here. If you want to see some of this stuff actually working, then go and approach one of the technical folks. And we'll show you.
12:24
