Building Blocks for ServiceNow Success

Explore the three most critical elements in building a truly CI/CD-enabled ServiceNow development pipeline

Implementing a continuous delivery model with ServiceNow requires that you both automate deployment and handle all the inherent complexities, including chaining of test automation, change management processes, and security and compliance tools. Creating a continuous deployment chain will turn your landscape into a truly agile continuous delivery factory and help your team keep up and get ahead.

1. Continuous Integration

In the waterfall development model, when multiple developers are working on a single project, code is merged infrequently, meaning that developers are often working with an out-of-date code base. When code is finally integrated (generally a manual process), many complex problems can arise, including missing libraries, broken dependencies, and more. Developers then work independently to fix these problems, creating new problems when the repaired code is integrated.

Traditional software development is file-based work, but ServiceNow development is platform-based. This difference means developers are working on a platform (the Now Platform) and not on a collection of files. Therefore the best way to apply CI principles to ServiceNow is a form of automation that provides controlled synchronization between your ServiceNow environments.

With synchronization in place, CI principles will allow you to automate development and QA flows (ATF & instance scans) to minimize manual steps, avoid costly conflict errors later in the process, and ensure instances are in sync across the entire organization. Incorporating CI comes with many additional benefits, such as setting up automated code scans for security and code quality checks, embedding automated testing (ATF or other) into the CI chain, and real-time notifications of problems - so you can resolve them early enough to avoid a bottleneck.

Obviously, while automation is the driving force behind efficient CI, it also includes the ability to pause for manual intervention (for approval, manual code review, and other processes that must be completed before code can be released).

2. Continuous Release

In the waterfall development model, releases are extremely infrequent and can only take place once all previous phases have been completed: design, coding, testing. While this model is easy to understand, it does not adapt well to complex projects with changing specifications. And if problems are found prior to release, it can lead to numerous delays.

Most ServiceNow developments currently use a waterfall model for production releases, which are even more complex than downstream deployments. Releases involve multiple applications and dependencies (for example, into global scope) and often include a combination of scoped applications, plugins, plugin activation, XML files, and update sets from different scopes, data, and elements that are not captured in update sets or scoped applications, and more.

Due to the complexity of production releases with ServiceNow, many organizations are using manual processes, relying on paper-based instructions that are difficult to follow and not repeatable. Plus, releases are often done during off-hours and on weekends to avoid the risk of downtime during work hours. The continuous release model begins with automation. Moving away from manual-release “run books” and adopting automated release packages can immediately reduce errors; eliminate overtime and weekend work; and ensure stability, compliance, and consistency.

But the benefits of moving to continuous release don’t end there. Adopting a true DevOps model gives you more control over release packaging.

That means you can track release versions across your environment, and ensure that releases are deployed in order, and even support automated multiple-scope releases.

3. Continuous Monitoring and Compliance

In the waterfall development model, it can take a lot of work to manage that final push to production. But then, developers can generally sit back, take a deep breath... and hope that nothing breaks that will send them back to the drawing board and have to scramble to fix code that misbehaves in production - or that contains performance issues, vulnerabilities, or security problems.

In most ServiceNow development environments, these issues don’t come to light until right before release - or later, with problems becoming even more costly to resolve once the app is in production. This is one of the areas where a DevOps model can be most valuable, letting ServiceNow adapt to a modern, faster-paced approach.

One of the biggest advances that come built into the DevOps process is continuous monitoring and compliance throughout all stages of development and production.

Generally, this involves testing teams as well as security, incorporating automation wherever possible. This essentially bakes automated verification testing and security scanning into the ongoing process.

With the DevOps model, deployment to production isn’t the end of the line; it’s an ongoing process of improving the app from a wide range of perspectives: usability, security, functionality, user experience, and more. For that reason, your DevOps solution needs to consider more than just orderly deployment - you need to consider quality and security, too.

When problems arise, your organization needs tools to help you track and pinpoint them accurately. This makes for easier debugging and faster solutions to a wide range of issues. An effective DevOps platform will provide a single command-and-control center for all releases, letting you take control of your environment. A comprehensive DevOps dashboard will also help you track ROI with relevant KPIs in a clear, measurable format.

With a continuous integration (CI) model, on the other hand, developers can avoid significant errors and problems further down the line. CI uses automation, in collaboration with a source code repository, to ensure that every single developer has the most current copy of the entire project code, which is generally updated several times throughout a typical working day.