“Azure DevOps” Rhymes with “Arcad ‘n’ Drops”

By Scott Heinlein 

Team Foundation Server…Visual Studio Team Services…Azure DevOps

Chances are, you’ve heard at least one of these terms before. Believe it or not, over the years this software suite has actually had a total of 13 names!
Most recently, it is known as Azure DevOps (unless that has already changed since writing this). But I am not here to pick fun of Microsoft’s naming habits (Arcad has a similar habit after all). I am here to talk about how your IBM i shop can utilize Microsoft’s most powerful development software, aside from perhaps Windows itself. Azure DevOps has existed in some iteration since 2006, but it seems to have hit its stride with the addition of git in 2013. TFS gained popularity for its all-in-one solution and easy setup, and for many years was the go-to for .NET projects. More recently, Azure DevOps has exploded in popularity with its focus on features like pipelines, and integration with platforms like GitHub. 

Note:If you still need on why you should be using git, I recommend reading the great articles here and here (just be sure to come back to this after). 

If you’re reading this, I assume you have at least some small interest in Azure DevOps. Maybe you’re aware that your company uses in some other area, and you had no idea that you could be using it for IBM i development. Maybe you use git on IBM i already, and are ready to upgrade to a full-featured repository host. Maybe you just like clicking on random things. In any case, this article serves as an introduction to Azure DevOps, integration with it, and how you can get started today. 

1. Azure Schmazure, what does it do?  

Azure DevOps is actually made up of five distinct, yet cleverly connected services. I could describe them, but I’ll let Microsoft do that for me –  

Most of these are pretty self-explanatory, and you may already own products that do the same things. The neat thing is, each of these services is optional and can be hidden from the interface if desired. For instance, it is common to use GitHub instead of Azure Repos, while still retaining all the functionality of the rest of the Azure DevOps suit. Azure DevOps biggest selling point is perhaps the fact that it’s a one-stop-shop for all things DevOps(sort of like Arcad!). Whereas other products have added additional services almost as an afterthought, each one of Azure DevOps services is fully featured and capable of supporting your enterprise needs. You can spend less time stringing together disparate products and more time building software.

2. Eco-friendly Pipelines

Probably the most powerful service of them all is Azure Pipelines. Pipelines, popularized by Jenkins, are a way to define your whole application lifecycle in one place. It has quickly become the standard method for implementing CI/CD. In Azure DevOps, your pipelines are defined with YAML and stored in the same git repository as your code. This means any configuration changes to your pipeline must (or at least, should) go through the same commit and review process as the rest of your code, and of course, since it’s in git, you have a deep and traceable history of changes. 

Note: There is the option of using the “classic” editor to configure your pipeline, but you will not get all the benefits of configuration-as-code. 

Azure Pipelines Agents are used to perform all build and release tasks. While Microsoft claims to support “any platform”, as IBM i users we are accustom to being lied to, which is the case here. Microsoft does not offer a pipeline agent for IBM i, which leads me to the next section…

3. A match made in DevOps heaven

Arcad has had support for TFS since all the way back in 2012, starting with the integration of TFS Work Items (Azure Boards). Not long after that, we added support for the SCM component, Azure Repos. Now, we have been successful in integrating Pipelines and Test Plans, with even more integration on the roadmap (now would be a good time to ask you to follow us on Linkedin and Twitter for updates regarding that!).

Webhooks, despite the name, are not one of Spiderman’s moves. Arcad utilizes webhooks to connect new branches in git with their counterpart on the IBM I- Arcad Versions. We can also consume webhooks from Azure DevOps upon branch deletion and any pushes to the repository. In short, webhooks are one of the ways Arcad can seamlessly sync the git and Arcad repositories.

Arcad also has a powerful CLI which allows Arcad, Verifier, and Drops actions to be securely executed from anywhere, including pipeline scripts. Our CLI is installed alongside the Azure Pipelines Agent to add the capability to perform Arcad related tasks. If you’re interested in a deep dive into this functionality, sign up for a demo here!

4. Sounds great, where do I start?

That answer depends heavily on where you are on your DevOps journey. Let’s take a look at some common scenarios I’ve encountered.

Scenario One: “My team is mostly 5250 and using a traditional waterfall methodology.”

When talking DevOps, tools are only one part of the equation, and they can only get you so far. If you’re at this stage, you have work to do on your company culture before you’ll receive the full benefit of a tool chain like Azure DevOps. But don’t despair! Every DevOps journey starts somewhere, and Arcad has experience helping teams at every stage of their journey. Together we can plan a roadmap with achievable milestones.

Scenario Two: “We have begun adopting agile methodologies but we have pain points and/or our tools are holding us back.”

You are the perfect candidate for a toolchain like this. You will see an immediate ROI using tools that compliment an agile methodology. Most people in this situation are lost in all the different tools and what combination of them would work best for their team, while retaining some or all of their current workflow. Azure DevOps is built to simplify this process by putting CI/CD pipeline, work tracking, and source code repository all in one tightly integrated platform. You can also keep certain services disabled until you’re ready to use them.

Scenario Three: “We are already using git and modern tools, but want to standardize on Azure DevOps.”

IBM i development teams are often one of the last remaining silos. I often hear from customers interested in breaking down that silo and incorporating them into their existing workflows. Arcad recognizes this, which is why we designed our integration to be totally open. We do not force you into predefined workflows. If you are already using Azure DevOps for Java, .NET, Node.js, etc. and have specific branching workflows and releases, we want to utilize that standard.

Note: Maybe none of these scenarios describe you well. In that case, get in touch with us and we can discuss your unique situation and goals.

5. Try it out

One thing you can do right now is download the “Team Explorer Everywhere” plugin for RDi. TEE is a plugin which connects to Azure DevOps so you can browse work items, clone repos, and more. And yes, it works with RDi! (at least V9.6). To get started, simply search “TEE” in the Eclipse Marketplace.

6.No more excuses

Gone are the days of the RPG developer sitting in the corner while everyone else plays with their shiny new toys. Excuses have run out and there’s no reason they can’t be using the same tools and workflow. Azure DevOps is just one of the many tools available to you with the help of Arcad. In my experience, the only thing “legacy” about legacy systems is the outdated workflows and mindset. Luckily, that is easy to change, and the future of the IBM i is looking brighter every day with more teams adopting modern DevOps workflows and tools.