It can seem as though release management is unnecessary, with the operations team being responsible for production runs, and the development team in charge of building the applications. This is far from true, however, as continuous delivery cannot run smoothly without it, and businesses that don’t integrate this way of working will soon fall behind the industry leaders.

What does release management do, and who does it help?

Release management is designed to help focus attention on the bigger picture rather than getting lost in the minute details. It enables teams to see their software during the production and development process, as well as understand how it fits into the overall business goals. It’s more than just coordinating the manufacture of the latest software – it enables all of the resources, the features and the testing to be coordinated, and aids understanding of the lifecycle of the applications. Essentially, true release management is not just about risk, but also everything that is needed to coordinate both the software moving into production as well as all of the different teams to ensure that every release meets company standards. It also simplifies communication between stakeholders so that they understand how the products of each individual team work together in the production environment.

However, for release management to be adopted fully, the traditional structure of the business needs to be updated along with it. Product managers need to run the entire deployment process from start to finish with the end goal being to ship finished software. In doing so, they become the link between the business, the customer and the development team.

The challenge is that product managers are probably not already release management experts, so they can’t always fulfill this role alone. This is where the product-oriented team can bring the most value. Release management responsibilities are changing as DevOps adoption matures, so these are being transferred to the product-oriented team, although there will likely still be support from a release management group.

Is release management still relevant today?

It is not unusual for businesses to question the benefits of release management, but this lack of understanding often comes from those who don’t have release management in place yet, or that have been unable to make it work well for them. The answer is simple: release management helps teams to manage the consolidation of DevOps and distributed, microservice-based architectures – a difficult task for any team to handle unassisted.

Monolithic applications, independent from all other applications, are still very common in today’s digital world, and the trouble with them is that it means that there are dependencies. Dependencies will make life difficult for anyone trying to run autonomously, as these applications must be able to connect up with all of the others. Many teams will also still possess more stable systems of record, such as ERP (Enterprise Resource Planning) applications. Again, managing these presents more complications, especially when changes are being made, and if the cycle includes a hybrid environment. Failing to integrate an appropriate release management strategy to manage this complex landscape can lead to potentially severe disruptions to the everyday business processes.

How do autonomous teams benefit?

Automation is improving in leaps and bounds. While autonomous teams are as well, there are business areas such as security or accessibility that will never be completely autonomous, so the teams will still rely on additional support. This is where release managers can really make an impact. Since they have visibility of the whole process to see how every tool operates both as a stand-alone and in conjunction with others, they can easily identify where bottlenecks are cropping up so that they can be resolved.

Plus, release management accounts for every part that can’t be automated. For businesses to get the most out of this, they should either implement coaching for the product manager or introduce a part-time release manager to assist the product team.

However, there will be times when people are not available to help, and so there are also tools that can be adopted to make this process smoother, such as a “virtual release manager” tool. Something like this can cover all of the delivery teams – it’s a mix of release process orchestration and templatised and standardised releases that are fully approved by the release management team. The templates provide an example of how the release should look, just like a blueprint for each release – they create a foundation for developers to build on with the exact details of the required release.

Along with this, businesses should shift all requirements for governance, risk and compliance in the development and delivery to the left. They need to create non-functional requirements so that development performs all of the essential tasks during the development cycle, not after. Introducing accessibility reviews of the design, threat modelling, or architecture review, for example, early in the process can reduce risk later on, as any problems can be picked up and resolved.

Release management has not seen the end of its life – not even close. It might be tricky to implement effectively when the company culture is not used to this way of working, but the overall benefits of the visibility and support that are gained through the introduction of release management outweigh the challenges teams may experience in the early stages. By persisting with integrating this different way of working, DevOps teams will find themselves working more collaboratively with each other, and producing higher quality service to all customers in the long-term.

Written By Jeff Keyes, Director of Product Marketing at Plutora.

The post Has release management seen the end of its life? appeared first on DevOps Online North America.

The typical journey from one software development model to another always requires a shift in perspective, with one or more members of the businesses delegating out different roles to other employees to suit where their strengths lie.

This approach is beneficial regardless of what the move from a legacy waterfall is going to. However, when a business chooses to move into scrum/agile, the job roles that are needed can be very different.

Teams often function in isolation to focus all of their attention on their own individual tasks, helping to ensure that the results are delivered as quickly and efficiently as possible.

How release management gets left in the cold

However, this isn’t an easy road to navigate – communication lines that were once so well-defined can become blurred. The typical management tie to the team is suddenly gone and the role of updating the product owner with the status of a project now lies with the scrum master – a technical role.

Agile teams are autonomous silos; that’s the benefit and the downfall, simultaneously. Each team works independently on purpose, but this makes it challenging to truly know where things are until they get to production – and these teams are still expected to deliver against one another. The question here is: where does management fit into all of this?

This problem becomes even more complex when scaled in a large enterprise. Going agile means compiling a bunch of fixed iterations into the schedule, but they still have an overall delivery schedule for the whole set of functionalities that has to be adhered to. Just because the methodology has changed, that doesn’t mean the mainframe by which the whole project is dependent upon has too.

There are still legacy components and traditional teams that the new system has to be coordinated around, and even once that has been achieved, the new system needs to successfully integrate with testing activities. For example, every release has compliance issues; enterprises need to do a security audit and approval process with operations and management before any new code is issued to end-users.

Taking all of this one step further, after agile comes continuous delivery and DevOps: essentially the ‘wild west’ of cultural change when compared to traditional models. Teams are given complete control over their direction; they deliver on demand, there are no more iterations, and the wider business is even further removed from tracking activity. In effect, management is left out in the cold.

The ice-breaker of a ‘bottoms up’ approach

So, how does an organisation overcome this management problem? The answer is to switch thinking from a ‘top down’ to ‘bottoms up’ approach. A change in leadership style that moves the focus away from commanding and directing the team to empowering them to work autonomously – but also in connection with wider business goals – is key. Management plays an integral role in making sure teams are talking to each other and collaborating effectively.

Bringing management back into managing development is achieved through the coordination of multiple delivery pipelines, and this is no easy feat. Coordinating when the release goes live against the release schedule as well as other factors such as change advisory boards and governance, compliance and testing issues means that management still has a lot of work on its hands.

Essentially, the release manager sits between the executive side and the individual teams and looks at ways to instil continuous improvement; in order to go faster, however, these pieces still all need to be put together.

Creating a warmer climate for all

In order for management to be successful, the manager needs to be looking at all the metrics of all the tools and aggregate them together. To do this manually would be painstaking, therefore tools that allow the consolidation of all features in the system – in real time – is the true enabler of continuous improvement.

What changes, then, is that the role of release management becomes more of a ‘management by exception’, whereby managers act like investigative reporters – looking for problems and areas that can be optimised in order to move the whole system forward. These tools can help organisations decide which team structures work best within the company and provide a historic look at metrics over time to see where improvements are being made – in turn, management as well as the quality of the delivery process improves.

Release managers therefore play a key role in the process of transitioning from legacy to a new software development model, as the ones who oversee the entire range of delivery pipelines. Part of making this as efficient as possible is having release managers lean upon the test environment managers for the support that the autonomous teams need, and thereby providing a suitable environment to manage the entire delivery lifecycle.

With these vital team members in place, the overall application delivery will be smoother and faster than ever before.

Jeff Keyes, is a director at Plutora

The post Making release management feel valued again appeared first on DevOps Online North America.

The post DevOps for digital enterprises appeared first on DevOps Online North America.

Introducing DevOps

Until a few years ago, organisations used to follow the waterfall method as part of the software lifecycle. The waterfall method is a step-by-step process, beginning with requirements analysis and ending with the delivery and implementation of the end product. This process, however, resulted in defective software pieces and would generally not be exactly what the product owner had in mind.

The mismatch took place mainly due to two reasons:

1. While the changes were being implemented one after the other, testing was performed only for critical response paths.
2. Once the software development process began, few requirements were deemed impossible to implement owing to system or process constraints.

Agile methodology took care of this flaw by ensuring that the product was developed in increments and was delivered for the product owner’s approval. Naturally, this helped teams work in a collaborative manner and kept the customer in loop. DevOps was introduced to further solidify the concept behind agile methodology. DevOps is looked upon as an opportunity to improve the delivery of a software application throughout the organisation.

Digital businesses have been on the rise lately, with leading organisations across industries looking to leverage the digital platform. Whether in the form of a mobile application, or as a form of interaction via the social media platforms, businesses are definitely going digital. This is giving them further opportunities to improve operations even after the software or product hits the market. The rise of digital businesses is a major factor that presses for faster release cycles.

Although there is no standard definition for the term “DevOps”, there is a unanimous agreement on the concept of DevOps. Essentially, DevOps puts emphasis on cross-collaboration and effective communication between software development teams and Information Technology stakeholders.

Doing DevOps the right way demands a conducive environment, one that helps automate release cycles and assures to accelerate the time-to-market of applications. There are many tools being provided by expert vendors that highlight various elements that make up for a conducive DevOps environment, covering the aspects of continuous integration, performance testing, release management, etc. It is just as important to create the culture of DevOps and understand how it would benefit in the organisational structure. Some of these aspects have been discussed in detail in this article.

By 2020, 50% of global enterprises will have implemented at least one application release automation solution, up from less than 10% today.
– Gartner

Doing DevOps right

Automation is key, especially when aiming for effective collaboration across teams. The automation aspect of DevOps in particular is garnering much attention over recent times. DevOps Release Management has become the topic of discussion and the point of strategy for CTOs and CIOs of many leading organisations. There are many start-ups that offer various products pertaining to release management. The release management solutions being provided by vendors are typically integrated with other open source, test, and build tools. This leads to customised solutions and tailor-made processes, and offers points of distinction for businesses.

The DevOps Release Management backdrop contains the following key areas among development, testing, and operations processes:

• Release management – Release management is fundamentally the entire process of managing, planning, scheduling, and controlling a software product through various stages and environments, including testing and deploying software releases.
• Integration across platforms – Although it is vital that an application or software is developed without bugs, it is equally crucial that the cross-platform integration is seamless. Whether it is being compatible across devices, or maintaining uniformity across software systems, the integrity of the software must be rigorously tested and seamless operational excellence is necessary to establish it in the market.
• Application lifecycle management – The application lifecycle starts with requirements gathering and extends to bug fixes and software updates long after the application hits the market. The whole lifecycle management requires robust testing techniques and effective tools to accelerate the overall operations process.
• Performance testing and monitoring – Performance testing assesses the functionality of a product and ensures that the users achieve the specifically desired results; while performance monitoring is on the operations end, making sure that the product or software is not impacted due to a sudden flow of traffic or other external factors.
• Continuous integration (CI) and continuous delivery (CD) – The process of CI and CD can either be manual or automated. Exploratory and user acceptance testing are manually done, while performance testing is typically done through automation.
• Continuous testing and DevTestOps: The age of customer that it is today, demands a steady, automated and intelligent testing that happens continuously. The paradigm of DevOps mandates continuous testing to ensure quality and speed become a paired option that is assured than becoming a choice. DevTestOps which is completely automation driven and which ensures the entire aspect of quality engineering starts early left in the cycle makes this a reality.

Creating a culture of DevOps

Culture plays a key role in the implementation of DevOps; however, this aspect is grossly overlooked. Although it makes sense to focus on the technical aspects of Agile and DevOps, it is essential to understand that accurate results can only be achieved through collaborative effort.

How does the cultural aspect help?

• It brings everyone on-board – Typically, organisations consist of several departments that work together to meet deliverables and continue to obtain business. By having an in-depth understanding of what DevOps brings to the table, and discussing how each team can contribute, team members will have a new-found appreciation for the implementation of this process.
• Work gets done with higher efficiency – Understanding that effective communication and collaborative effort is required can help get things done with higher efficiency. It is important for the team members to understand that they need to help out other teams, and that they are not pitted against one another in the process. The software developer cannot be threatened by a QA engineer, and the Operations executive needs to be open-minded when the developer suggests an alternative strategy.
• It helps employees align with company’s objectives – It is important to understand how an organisation is portraying itself in the market. It helps all employees understand the current market strategy, so that the message is spread wide and clear. This helps excellently with brand building and, subsequently, brand recall.

How can organisations nurture DevOps culturally?

• Leverage the power of social media – By being active on social media, employees can gain different perspectives about DevOps, and what it means to teams working in different departments.
• Company sessions, conferences, and events – When organiations have employees working together but are not co-located, it is important to bring them together for sessions, conferences, and events based on the theme of DevOps. This helps solidify the commitment of working towards a common goal.
• Emphasis on document and professional terminology – It is important to correct and insist on using terminology related to DevOps right from the initial stages. It helps cement knowledge around the topic and can make a tremendous difference while communicating with clients and prospective leads.

In conclusion

According to industry leaders, release automation tools enable best practices for applications. They help reduce complexity and standardises processes. Manual processes have been acknowledged as severely prone to errors and delay releases significantly. A faster application release, quicker time to market, and longer sustainability gives organisations an edge and keeps them relevant in the market scenario. In the year of 2017, and over the next few years, this is a trend that will only be on the rise. Quality engineering and quality assurance delve into the system architecture and ensure that the end-to-end functionality and integrity of the application is maintained. DevTestOps will be a key enabler for completeness for DevOps and Cigniti Technologies consists of a team of SDETS and experts that have done extensive research on accelerating the process of testing by maintaining software quality as the primary objective.

Edited for web by Jordan Platt.

The post Incorporating DevOps the right way appeared first on DevOps Online North America.