Author: Andrew Ramadan  |   Published: November 10, 2021

Tell me if this scenario sounds familiar. You’re the product owner on a large-scale project with many members on the implementation team. One of the people on your team is Dan the Developer. You’ve noticed that Dan’s completed code, which you already approved during UAT, won’t arrive in production for weeks. Your user base is frustrated by this because they’d like their changes and fixes faster. Dan says this is hard on him as well. This process requires him to track the pending code with his current work to ensure it won’t break the pending code. Sometimes when Dan’s code is deployed, you notice that there are errors and delays as well. Dan says this is related to dependency errors because his code is compatible with his development environment, but not the production environment.

Another person on your team is Suzy the Systems Administrator. Suzy is responsible for ensuring production has limited downtime, managing the servers, and helping deploy code into the production environment. Generally, Suzy blocks off a day of the month for her deployments. Suzy does this because code can often require tweaks to be compatible with the production environment. It’s also her responsibility to diagnose issues that come as a result of the deployments, so she doesn’t want to risk system downtime. Suzy seems overwhelmed by this process and feels like the developers are passing the burden off to her.

As a product owner or major stakeholder, this situation can be daunting to help fix. The implementation team you oversee seems like they are working hard to accomplish their tasks, but your user base is still frustrated with their delivery speed. What role can you play to address some of the issues that often come up with your team’s delivery?

How can we help Dan and Suzy share the responsibility equally and work more cohesively to deploy code faster?

Dan and Suzy should implement DevOps in their delivery process. DevOps is the process of combining software development and IT operations tasks through use of automation tools. The goal is to make these roles have shared responsibility rather than operate as individual teams. DevOps can speed up delivery time, maintain high-quality, and break down miscommunications and silos on the implementation team. The numbers back up that DevOps teams are effective at doing this. 71% of DevOps teams can recover from failures in less than 60 minutes while 40% of traditional IT Ops need over an hour to recover. Additionally,  DevOps teams need approximately 36.6 minutes to release an application whereas Traditional IT Ops teams need about 85.1 minutes.

What are the key differences in the DevOps process?

Within DevOps, developers are focused on writing smaller pieces of code for deployments in just a few hours, instead of large pieces of software over weeks. There is also a change in focus of what code developers write and focus on. There is an emphasis on automation scripts instead of configuring software and infrastructure code manually. This makes it significantly easier on individuals as you scale and add servers. A good way to visualize this concept is to picture yourself as the head coach on a football team. As head coach, you assemble a playbook and let your players run plays out of that playbook. It doesn’t matter which players get switched in or out of the lineup, the play doesn’t change. Additionally, other teams could be given this playbook and the plays would remain the same. This is similar to spinning up a new server and giving it the same automation code.

What key tools make up DevOps?

DevOps processes typically have multiple parts that make them successful. One aspect is a central repository that is used as a source control system for code. A popular tool is GitHub to accomplish this. This allows all of the code to be consolidated in one place and developers to be aware of each other’s changes. In a Low Code environment, the code and asset version repository may be contained within the platform. It’s important to understand that this is only part of the process. An important distinction from just using GitHub to a DevOps process is a Continuous Integration tool such as Jenkins. This is a key contributor to the shared responsibility of the development and operations teams.

Jenkins is a tool that provides continuous development, testing, and deployment of newly created code. It primarily uses a continuous integration server to run automated tests against what was pushed by a developer. If the tests don’t pass, then they will get sent back to the developer. This is helpful for two reasons. First, it ensures the developer isn’t pushing code that will break the build, causing delays and issues for users. Secondly, it creates a situation where the developer can run tests in a production environment to verify that the code will work in this environment rather than just a development one. This takes off some of the pressure we detailed that Suzy has in our example above.

DevOps and Low Code

Many enterprise low-code technology providers include DevOps capabilities out of the box within the platform. For example, Appian, VPS’ preferred low-code partner, has many out of the box capabilities to implement DevOps processes. In Appian, you can export application packages from a development environment to test or production with just a click of a button or , as was introduced earlier this year, via a deployment API call. Developers have the ability to package database scripts and plugin scripts as a part of their packages as well. A main theme of this capability is reusability. In order to accelerate development and delivery, Appian’s low code “package” concept allows for simplified management or reusable code modules.

Appian can send packages to continuous integration environments where automated testing occurs on the code. The platform can also provide warnings for issues and discrepancies it detects when deploying application package changes between environments. The visualization of all of these processes within the Appian platform also makes it easier for less technical stakeholders to follow along.

Vision Point Systems is an expert Appian implementation partner. Learn more about our expert services.

Author

Andrew Ramadan

I’m a Business Development Manager at Vision Point Systems where I guide existing and potential accounts through the entire customer lifecycle, overseeing discovery to account management and ensuring they attain desired outcomes from VPS services and solutions. I also assist our executive team in developing our go-to-market strategy for our services team and solutions, developed in collaboration with our technology partners Appian, Twilio, Intercom, and AWS.

Before this role, I spent five years as a technical consultant, primarily leading software development teams building on the Appian platform.

See author's posts