Enterprise Release Management Success

5 Barriers to Successfully Implementing Enterprise Release Management

The sister of IT & Test Environments Management is Release Management, and when it comes to delivering the capability at scale, that is at an organizational level, then we are talking “Enterprise Release Management” (ERM). ERM is the overarching governance framework that brings our different stakeholders, projects and teams together so we can effectively scope, approve, implement and ultimately deploy our changes effectively and in unison.

One could say, ERM bridges the gap between corporate strategy and DevOps.

 

However, implementing an ERM framework isn’t necessarily done, as many companies still don’t do it, nor is it necessarily trivial. In fact, there are many barriers to successfully implementing ERM and ultimately ensuring effective and scalable delivery.

With that in mind, let's look at a few of the top barriers to ERM success.

  1. End-to-End Process Verification

One of the first steps to successfully implement ERM is to ensure that each stage in the end-to-end pipeline is complete and valid. It's critical that you don't overlook some very important processes in your pipeline like compliance or security assertions. Verifying these types of processes in the software development lifecycle (SDLC) is a barrier in ERM because it is complicated and requires a large number of revisions.

When a project starts, the workflow is simple. But as it grows, things get more and more complicated. You need more people, more dependencies, more checks, more systems, and more software changes. Then you need a standard process. Unified practices and processes help organizations ensure that every state is completed properly.

Integrating multiple projects and different departments is challenging. Every department has different goals and objectives, so it's not surprising that some departments have conflicts with each other. C-level executives put pressure on managers, who then put pressure on developers, to deliver on time. At the same time, developers pressure IT operators to release software changes faster, but IT ops are responsible for the system's stability and have to consider how every new change might put that stability at risk. This chain creates conflict constantly, sometimes forcing personnel involved in SDLC to break the rules and bypass some processes.

As you grow, it will become more difficult to ensure that every stage of the SDLC is completed. Help your teams understand why every piece of the ERM puzzle is important and be clear why some processes can't be left incomplete. A good set of checkmarks (or milestones and gates) will definitely make the verification process less painful. But for that, you need automation, which brings us to the next barrier.

  1. Manual Procedures

The easiest way to start managing portfolio releases is with manual procedures. But having a spreadsheet where you control the priorities and release dates of projects doesn't scale well when you need to integrate more people and projects. Automate every task, process, and documentation you can. Don't think about it—just do it. Breaking the barrier of manually managing releases will let you focus on how to speed up software delivery.

Not everything can or should be automated—you still need someone to decide which releases are good to go and when. But getting rid of even some manual procedures is going to change the way you do things in your organization. The process will start by centralizing requests (or registration) for changes, which can come from several sources like marketing, management, and customers. Then you can start recording how these requests move through SDLC.

Leaving trails in the end-to-end process helps create status and compliance reports. You can easily leave trails when you integrate automatically—not only teams and projects, but also build, configuration, and deployment tools like Jenkins, Ansible, or Spinnaker. When you integrate tools like these into your ERM, you'll have information on how much time it takes for the company to deliver software change and complete critical tasks and you'll be able to prove to auditors that you're taking care of everything the company needs in order to comply with regulations.

Manually managing enterprise releases will give you headaches. People will end up spending too much time on things that don't necessarily add value to the customer. Break this barrier with automation because life is too short to keep doing boring things manually.

  1. Visibility for the Entire Workflow

It's not easy to get the big picture of the release pipeline. There are too many required processes in the enterprise's journey to deliver software changes. And leaving a trail in each stage is the key to increasing visibility. A lack of visibility is a significant barrier to improving the software release process.

Knowing where you spend the majority of your time in the release pipeline lets you focus your work efficiently. Maybe you'll find out that you're spending too much time manually configuring applications. In that case, you might need to centralize and automate configuration management.

Or maybe you're spending too much time releasing software after it has been approved in a certain environment, like dev. That could be a sign that you're doing deployments differently in each environment. You might need to focus on preparing a good test environment framework.

But having more visibility isn't just about improving the process. If management wants updated information about how the project is going, they don't need to interrupt the team. Is the project going to be ready for the agreed release date? In which stage is it currently? Did the software pass all tests? Which team has the hot potato now? All sorts of information tell the story and status of a project, and it's all critical to the success of ERM. And you need to have that information up to date and in real time. Having enough visibility helps the team to communicate and coordinate better.

  1. Long Delays Between Releases

One of the main purposes of the ERM framework is to spend less time on releases. At least, that should be the expectation. The amount of time you spend on releases could become a barrier to succeeding in ERM.

ERM is a good framework to plan the date of a release, and that's good to know. But knowing that a release is going to happen in two months doesn't add a ton of value to customers or to management. By that time, it might be too late to release software changes, especially if you need to fix anything after the fact. When you have enough visibility, it becomes obvious where you can reduce the time a release takes.

The amount of time between releases can also increase if you fixed a bug that broke something else at the same time. You won't expect to have a high rate of deployment failures when you implement ERM.

Reasons may vary, but here's a list of things that I've seen affecting time between releases:

  • Needing to coordinate between too many teams, usually in a sequential manner, not in parallel.
  • Waiting to have enough changes to release because it's "less risky."
  • Lacking production-like environments, which help maintain consistency.
  • Hermetically building and packaging the artifacts more than once.
  • Dealing with messy and complex configuration management.

ERM should aim to break the pattern of long delays between releases by working to improve software architectures. There are practices like infrastructure as code, configuration management, self-provisioned environment, and others that ERM can orchestrate.

  1. Same Release Cadence for Everyone

Not only does waiting for someone else to finish their part of the job to release a software change cause a lot of problems, but it could also become a barrier to ERM's success. You could end up accumulating too many changes, which, as we just discussed, increases the risk of failure and the time between releases. What should the team that's waiting do? Keep waiting? I don't think so—they usually start working on something else, which means they could be interrupted constantly to help with the pending release.

Let me give you an example of a common scenario. The developers have just finished their code changes to use a new column from a table in the database. Now they need to wait for the DBAs to add the new column, and after that, the code is ready for the release. Seems like a decent system, right? Wrong. That's just a sign that the architecture is highly dependent on the database.

Developers should be able to release software without having to worry that any dependency—like the database—has everything the application needs. What if database changes take a while to be ready for the release? No problem; the application code is using feature flags, and it's just a matter of releasing the code with the feature turned off.

What if the database changes have problems after the release? No problem; the application is resilient enough to expect problems in the database. Now that's a way of working that doesn't need complex solutions. Code apps so that they're ready for a release at all times.

If you miss the train on a release, you need to wait for the next one to come, and that should be OK. It's better to wait to release something until you are sure that it won't have a negative impact on the company's revenue. But as soon as it's ready, ship it.

Conclusion: Agility Helps Break Barriers

As you can see, not all the barriers I described are related to a specific stage of deployment. Many teams play significant roles in the success of ERM, beginning when a project is planned in management offices to when it's being delivered to end users.

Automation; traceability; versioning control; decoupling architectures; releasing small, frequent changes; and other DevOps and Agile practices are going to help you successfully implement ERM. But also having the proper tools in place are key. Because if you only have a hammer, everything looks like a nail.

Barriers to a successful enterprise release management will always exist. But as long as you continue to find opportunities to improve, success is practically guaranteed.

Contribution by Christian. Christian Meléndez is a technologist that started as a software developer and has more recently become a cloud architect focused on implementing continuous delivery pipelines with applications in several flavors, including .NET, Node.js, and Java, often using Docker containers.

Top 20 DevOps Tools 2018. IT and Test Environment Management Winners.

Rise of the TEM Tools (DevOps Winners 2018)

After years in obscurity it appears that IT & Test Environment Management tools are now starting to get noticed.

This year saw several IT Environment Management products being nominated by CIOReview as the most promising DevOps tools. Most probably in recognition of the importance of managing your IT Environment & Operations to achieve "DevOps at Scale" and ultimately better manage you cloud landscape.

Congratulations to the winners Enov8 and the other CIO Review Top 20.

--- News Source ---

Enov8, the Enterprise IT Intelligence company, has been named winner of this year’s, 2018, CIOReview “20 Most Promising DevOps Solution Providers”.

SYDNEY, NSW, AUSTRALIA, July 17, 2018 /EINPresswire.com/ -- Enov8, the Enterprise IT Intelligence company, from Sydney Australia, has been named winner of this year’s, 2018, CIOReview “20 Most Promising DevOps Solution Providers”.

A somewhat unique winner, Enov8 goes “against the grain” of providing a “simple” DevOps point solution, and provides a broader “business intelligence” platform that helps organizations run their Enterprise DevOps more effectively through the embracement of methods that help the organization better understand and manage their complex IT landscape and delivery chain operations.

In response to the news, Enov8’s Executive Director, Niall Crawford said: “CIOReview selected a great list* of companies this year. To be selected as the overall winner of this prestigious award was fantastic and I believe it was partly in recognition that the industry is evolving and organizations now need to address the ‘DevOps at Scale’ problem and, off-course, an endorsement of Enov8’s hard work and innovative approach in this space.”

CIOReview Top 20 List*: https://devops.cioreview.com/vendors/most-promising-devops-solution-providers-2018.html

Note: This award follows some of Enov8’s recent achievements which include various big wins with global enterprises (banking, telecom and retail) and significant partnership announcements with some of the world’s largest technology service provider.

About Enov8
Enov8 is a leading “Enterprise IT Intelligence” and “Enterprise DevOps” innovator, with solutions that support IT & Test Environment Management, Release Management and Data Management. Enov8’s philosophy is to help organizations be “Agile at Scale” through enhanced transparency and control of their IT landscape and operations.

About CIOReview
CIOReview is a leading technology magazine that has been at the forefront of guiding organizations through the continuously disruptive landscape and providing enterprise solutions to redefine the business goals of enterprises tomorrow. Recognized as a principal and reliable source of information, CIOReview offers a ground-breaking platform allowing decision makers to share their insights, which in turn provides entrepreneurs with analysis on information technology trends and the broader environment.

Reference: EINnews.

 

Service Virtualization for Test Environments

Test Environment Best Practice – Service Virtualization

Service Virtualization

Service virtualization is an evolution of methods like "mocking" and "stubbing." These techniques allow you to replace dependencies in test environments, enabling teams to keep testing their software without the constraints created by services out of their control.

It's fairly common to rely on external resources that are expensive to use and/or not available to every developer. Some teams try to work around these limitations by writing their own mock code. Simulating a few interactions might get them results in the short term, but it’s unproductive to keep this effort isolated.

An alternative is service virtualization, which allows teams across your organization to use the same simulated dependencies effectively. In this post, I’ll talk about the benefits of service virtualization and highlight how having a clear process, consistent governance, and operation standards are vital to implementing a platform like this.

What Are the Benefits of Service Virtualization?

When testing in the early phases of your development cycle, developers often don't have access to all the necessary systems that will make software testing fully representative. Reasons may vary, but common examples include systems on legacy platforms, prohibitive licensing costs, and systems that generate financial transactions or cost money each time they’re queried.

This kind of constraint creates bottlenecks, forcing your teams to wait if they want to access resources. Service virtualization will enable them to replace dependencies with components and data that reliably resemble the production site.

When Should We Use Service Virtualization?

Teams that have restricted access to service dependencies tend to produce code with lower test coverage. In many cases, these teams delay most of their testing until later development phases. But fixing bugs in the later stages of the development process is more expensive, not to mention frustrating for developers.

By using service virtualization as early as possible in your development process, you're enabling your teams to increase their capacity to fix bugs that would show up only in a production environment. This is more efficient, and it gets you closer to achieving true DevOps.

How Do We Implement It?

Once you’ve picked a certain framework or tool for service virtualization, select a service with a high rate of interaction problems. Figure out your best candidate for "problematic service dependency." Record enough data to replicate this component, set up a virtualized service, and configure your code to interact with it.

In order to standardize the use of this new resource, there should be a unique source of truth where you store (and can later find) your virtualized service specifications. One common option is a version control repository like Git. Having this source of truth will help you increase adoption among other development teams. As soon as other people start reaping the benefits, they’ll be interested in virtualizing other troublesome service dependencies.

You should also create guidelines to help teams follow standards and conventions. If your organization is implementing service virtualization through an open source framework, you’ll have to enforce standardization yourself; your virtualized services should follow a common set of rules so they’re reusable across teams.

How Do We Keep a Virtualized Service Close to the Real Thing?

"Recording sessions" is a common method of service virtualization. It facilitates the process of capturing data that can be later used to simulate inputs to client services. The whole purpose is to reply to requests made by your tested code with representative samples of data.

There are other non-functional requirements you could validate, like simulating network instability or unusual response times. This is valuable for developers of mobile applications who can't assume their client application is going to enjoy a stable connection at all times.

Last but not least, persuade people to have their virtualized services automated and continuously tested. Service virtualization will be effective only when it closely represents how data is actually served in production. In order to keep up with external changes, it's critical to have automatic and reproducible processes. If you start to slack on testing, your virtualized services will become obstacles.

Whose Work Is All This?

I've seen software shops where every possible form of testing is sent to a quality assurance (QA) team. I'm not a supporter of this method.

Testers have unique skills, but their role is assisting developers when they write tests for their own code. I see service virtualization as an enterprise-wide traversal process. It needs involvement from all these team members:

  • Developers. Because of their familiarity with your business codebase, developers can quickly reason how each service interaction will affect program behavior.
  • Operators. They can quickly map how interactions may turn into failure scenarios under real-world conditions. Even if your organization has transitioned to DevOps, operators usually control firewall restrictions and endpoint configurations that are necessary for implementing service virtualization.
  • Testers (QA). They are deeply involved with reproducing conditions that might occur when your end users operate your software. Testers also serve as an active audience in the integration process, which gives them a holistic understanding of your service interactions.
  • Test Environment Managers. To ensure these "Virtual Systems" are properly advertised, provisioned, configured and shared/coordinated across the consumers (Test Teams & Projects).

Wait, Isn't This More Work?

A group of early adopters may absorb additional work in the initial phases of service virtualization. But they'll learn and document processes that other teams can then include in their development cycles, which will improve efficiency overall. Make sure to raise awareness of your initial scope to avoid frustration caused by unmet expectations. Transparency and clear goals are very important.

How Do We Get Started?

Any decision to implement a new tool should be made within the boundaries of your budget; that's why it's vital to know what dependencies are worth simulating. Locating bottlenecks in your development cycle is the first step. Then, evaluate how much your cycle could improve by using service virtualization and select a service you can quickly implement as a prototype.

Consult your teams. Ask them for input on how to obfuscate data to avoid security issues, and be sure to involve the necessary stakeholders to provide the basic infrastructure. Emphasize the importance of putting all these pieces together through automatic and reproducible methods.

A Word of Advice: Remember to Measure

Find metrics for lead times, time to market, or any other relevant measurements from your software development cycle in order to find spots where you can quickly improve. This will help your team create valuable impact in the short term.

Project managers would rather assign long time-frames that might allow projects to finish ahead of schedule, rather than tight deadlines that might cause projects to push back their due dates. Pay attention to these patterns; you might detect hidden delays in processes like infrastructure deployment and testing reconfiguration. Look for these situations as opportunities to automate, standardize, and promote change.

Authored by: Carlos “Kami” Maldonado