IBM i DevOps TechTalk
DROPS – Part 1 #17

Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi and I’ll be your host today. Today we’re going to discuss a really significant topic in the world of DevOps. As many of you already know, ARCAD is a comprehensive suite of tools that includes everything you need to do DevOps, including deployment.
We do it using ARCAD DROPS. Joining in on the discussion today will be Alan Ashley, a senior solutions architect here at ARCAD, and Jeff Tickner, the CTO of North America.

Alan Ashley – So, Jeff, we’ve talked a lot about DevOps over the past techtalks. We’ve talked about workflows. And one of the things that’s always at the end of this workflow is deployments. What can you tell us about some of the complexities. And then go into looking at an IBM i deployment and how maybe it works with other OSes that are out there that are always involved with an IBM i?

Jeff Tickner – Yes. So that’s the thing I’ve seen changing over time is that, deployments are becoming more complicated because people are providing gooey interfaces often web based or other tools that have an interface to their business logic and their DB2 database. And what I see is the easiest way to support testing is to have extra LPARs.
So I see more and more multiparse shops where QA has the same library names as everything else. Instead of just using library list, because library list doesn’t work that well with those other tools. So now we have multiple systems, more complex deployment. It’s much harder to manage in a more traditional way.

A.A. – So and you mentioned that they’re starting to get these front-end. And I’ve seen this too. And I mentioned it to customers that you never find an IBM i that doesn’t have a front-end these days. And we always have these deployments that go together. And now you can start to bring those in. And I know in ARCAD we have this tool called DROPS that handles that aspect for us.
I know that it can reach out to Git and pull that information, and it can reach into an ARCAD repository and create those artifacts, and it can reach in to other different OSes and databases and begin to build out. I guess it’s called an artifact within DROPS. So what are some of the benefits of bringing in an IBM i, and maybe having it within the same campaign of deployments with the other platforms?

J.T. – Yes, the start of DROPS was our customers, they wanted to support these multiple platforms. And so when we developed DROPS, it does run on the IBM i, but it can manage any kind of platform. I’ve seen it do any kind of deployment. I’ve seen it do all kinds of incredible stuff.
But the key here is that you can have a synchronous deployment where you’re updating the interface on a windows server, and also changes to the DB2 database on the IBM i and maybe some RPG that’s providing the business logic. And it’s a synchronous deploy. It’s promoting those objects out to those two different platforms from a single identifiable release and DROPS.
So it allows you to say, I have a change that’s potentially disruptive. And either everything has to change or I don’t want anything to change. I don’t want to double the size of my field and then have the user interface in the web still pushing back half the size. I have to have everything talking the same structure and so DROPS is what does that.

A.A. – Now before we talk about more of the benefits that come out with using DROPS, I can make the assumption here that DROPS can be used within like a pipeline or a CLI type of interface.

J.T. – Yes. It was designed from the beginning because we were trying to open up our tools in an embrace open source. So, it can talk to anything. We have all kinds of integration with tools. We can probably talk about that in more depth in the future. But, I’ve integrated it with all kinds of things.
And again, the goal here is that because the other platform, the user interface are normally already using DevOps workflow, DevOps techniques, the ability to integrate with them makes it easier to synchronize these deployments.

A.A. – So going back to some of the benefits, because synchronization of the deployments is one of the keys here. And I know in the IBM i said we really look at security and being able to maybe have a separation of duties. But now it sounds like we’re also allowing other platforms to get involved. How does DROPS handle those types of approvals and separation of duties and does it have to be an IBM i person using this?

J.T. – No. That’s the other thing too, is that we developed our own user management, our own database of users in DROPS. You know, as long as managing to me, as well as managing the packages, we also manage the users. And so you can have IBM i users and non IBM i users interacting with IBM i deployments.
So a windows guy who doesn’t know what an IBM i, is can actually see what’s happening during an IBM i deployment. Now, because we’re pushing the real time deployment log back to the web interface of DROPS. So it’s very easy to access and we can make those people a common user class in DROPS, or we can do true separation of duties and say, oh, this is the release team.
These are the developers. The release team can press the button, the developers can approve or vice versa. We’ve have quite some complex, set ups and DROPS there as far as keeping separation of duties, meeting the requirements of the customer.

A.A. – And I know that you’ve mentioned the console and the one thing that comes to mind in working with some of my customers in the past is the operations team, who really may not know anything about any of the platforms. They can get this visual on the web platform and say, okay, this one’s ready to go. It’s got all the approvals and they can hit deploy.
They can hit the run or the validate button that kicks off that final step. And along with that, they can schedule it as well. So once you get to that certain point in that journey from you’ve got your artifacts bill, you’ve got it from the IBM i, you’ve got it from the windows. Now, it can just kind of flow through in your operations team literally watch it go through, stop it.
If it needs to be stopped and reviewed and send out those notifications if need be. And that’s what’s really nice about this, is it can be run from a central location of people that may not be involved with the actual development, but the actual DevOps flow for that.

J.T. – Right. And you can set the rules that you want to apply for a specific deployment process. You can have different rules for different platforms. And of course, the most amazing thing is that you can rollback across all these platforms also. So if there’s a problem on the windows side where the deployment, they’re doing smoke testing after deployments complete and they’re like, oh geez, the web pages don’t load anymore and the database is updated, then that release team or those folks act with access to web interface can say rollback. We don’t want half of it out there and half of it not out there. Rollback. And the rollback is just like the deployment. It takes care of all the platforms. So you either have it all go or have none of it go.
So no mess is Monday morning where you know the database is updated and the interface isn’t, or the interface is updated and the databases and no more pizza parties all weekend. You fight through multiple platforms, different teams, talking back and forth. It’s all synchronous.

A.A. – And I know one of the things that when you’re talking about the the rollbacks part of this is that you’re dealing with a kind of a singularity of an artifact. And this artifact can also then be deployed to, let’s say you have a training environment that you want to update, and you need to refresh that. You can redeploy that multiple times, just like you can roll it back.
You can push it forward as well, just to that singular release strategy that is built into DROPS. One of the last things that always comes up is the audit. What kind of audits does DROPS bring to the table as far as you know, what’s been done. How is that handled?

J.T. – So the biggest thing is the approval. So it’s important to see and obviously we can see who has triggered something. So when I integrate with any kind of automation tool, I like to have a specific profile for that interface. So we can see that trigger came from what platform and so on.
But the approval I can actually approve, I can have a deployment process that updates five systems and say, I need a different person to approve each system. And we can say they can go as they get approved or they can wait. So a system one has to go and it’s that person. System two has to go, and it’s that person.
And when I say systems this could be platforms. You could say that the windows guys have to say, yeah, the windows stuff when it’s approved. And then the IBM i can go or vice versa. Or it could be my test environment, my training environment, my family, my production environment. So it’s quite granular in, control over approval.
And also in turn, when you look at the history of it, you can see who did each thing. So it’s really, really, high level of visibility to what’s happened. And we can of course manage the object level so we can tell you on the IBM i, because that’s her specialty what object went to what library.
Even if you have a complex topology, the files went to the file library and the programs went to the program library or maybe even something more complex. I’ve seen all kinds of things.

A.A. – Yes, I know. I like looking at being able to see what was in the safe file that was deployed, and you can actually see all the different components and being able to kind of dig into it so that you always know exactly what was sent out in each release. Now some of the things we’ve talked about today are kind of the basics.
This kind of DROPS’ 101 aspects of deployments and with any good tool, it has the ability to start to become more advanced based off of your needs. And I know we don’t want to get into it today, but what are some of the other areas that DROPS can get into? Can it work with Ansible and how does it function in that standpoint?Can it do YAML languages?

J.T. – Yes. So it does actually have its own pipeline toolwithin it. So you can have a controlled outside by a pipeline, Jenkins or what have you, Azure pipelines, but it actually has its own internal pipeline tool also to manage complex environments and appropriate progression. But it can be scripted. So the deployments themselves, we understand the IBM i very well, but you might have very special requirements for some systems or for some platforms.
And you can use any kind of scripting, including Ansible. Ansible is an amazing tool. Now that IBM has provided all these great tasks for us to do. It’s a very specific tasks. And the IBM i like shot a subsystem down or install a PTF or check that a PTF is there. But we can do similar stuff on other platforms as well by using the existing tools that are out there.
And Ansible has a lot of tasks out there, but if the customer already has a tool, most of these customers you’re working with, when we talk about bringing in the other platforms and providing this synchronous deployment, they already have an install process. But there’s normally somebody saying, is it time? And running their script or whatever, and we can take that script, parameterize it and put it into DROPS so that you have a consistent process.
And that’s the goal there is that you have a consistent deployment process. When you have consistency in the deployment, you get consistent results. And if it doesn’t work out, that’s where a rollback comes in where you can rollback that and rollback all the platforms.

A.A. – Now, I know one of the things that I want to dive into the next time we talk about DROPS is I really want to kind of dive into the area you mentioned Ansible. I do want to dive into that and see how that can fit into a more complex environment. So we’ll talk about that next time. Is there anything else within DROPS?
I know we’ve talked about so much and just a little bit about amount of time here. We’ve talked about approvals, separation of duties, the web interface. Is there any last closing comment that you want to put forth on DROPS?

J.T. – The beauty of DROPS is that it’s so customizable so you can get started with it very quickly if you have simple requirements. But if you have complex requirements, it can handle it. I’ve done some pretty amazing stuff with it.

R.B. – Thanks guys. So DROPS is basically application release orchestration. It has DevOps integration and it can do automatic rollbacks. It’s designed to streamline your deployment process, enhance your reliability, and improve your efficiency. Thanks for listening.