devopsy.kinsta.cloud

Tag: user experience

Death of the Release: The Move to Continuous Delivery and Experimentation

As we move from continuous delivery to continuous experimentation, we also must develop new practices

As software development processes have evolved, we have mostly said goodbye to the idea of defined product versions. Many modern product delivery teams are taking this a step further—even the concept of a “product release” is starting to fade. Instead, products are becoming a fluid, rapidly evolving set of features, assembled uniquely for any given user.

Twenty-five years ago, the new release of a software product was a notable event. The marketing department would even insist on a catchy version name for the release. Internet Explorer 6, Office 2000, Windows XP, OSX Mountain Lion. This is still the case for a few types of software—operating systems being the most notable—but for most of the software products we use daily the concept of a version has faded away. What version of Google Maps are you using these days? How about Facebook? Twitter? As far as the end user is concerned, there is no version, just “current.”

A few different forces have moved software products away from release versions. The rise of agile software methodologies and associated practices such as continuous delivery has allowed software teams to tighten up software delivery cycles dramatically. Products that once were released every few months are now updated every few days.

In parallel, the growing capabilities of the web as a platform has moved many products off of the desktop and into the browser. This has greatly reduced the friction involved in releasing a new version of a product. Pushing a code change to servers you manage is a lot easier than persuading your users to download and install an update.

Finally, there has been an architectural shift away from large monolithic systems toward service-oriented architectures and, in recent years, microservices. These modern architectures consist of many small, independently deployable units. This again reduces the friction around deploying a code change by reducing the scope of the deployment to one specific service.

These forces combined have led to software release cycles shortening dramatically, from multiple months or years between each release to a rate of weekly, then daily, then hourly software delivery for some teams. Delivery of a new software release has moved from a marketing event with fanfare to something that is happening almost continuously, even for large products. As far back as 2011, engineers at Amazon were releasing changes to production every 11.6 seconds.

As teams move from a monolith to microservices there is no longer one deployable unit, but rather an ecosystem of independently deployable services. It no longer makes sense to ask which version of a release is running in an environment. Instead, we must ask which version is running for each individual service.

And then there’s feature flagging. One can think of a feature-flagged service as existing in a sort of quantum superposition of potential code paths, resolving to a specific set separately for each request. This means that a service’s behavior in an environment can change radically without any code deployment and without any observable change to the release version.

Now, as we move from continuous delivery to continuous experimentation, we are reaching the point where it is no longer useful to attempt to describe the current running software in terms of a “release,” or even a set of releases. The situation has become a lot more fluid.

Coping in a Post-Release World

Modern approaches like microservices and continuous experimentation are a boon to product delivery teams. They allow us to move faster with more safety, thanks to the tight feedback loops they enable. But this new world also brings challenges.

It can be a lot more difficult to diagnose a bug when you are not sure what code was involved. The load on testers becomes greater as they need to consider the interaction between multiple releases of different services—each with different feature flags which can behave differently from request to request.

From a user’s perspective, a product’s rapid pace of change can be a little overwhelming. New features arriving frequently is nice, but having the UI change every time you log in can be disorienting. Even worse is when a feature is available one day and then gone the next. Users can also be wary of the idea that they are not getting the same experience as other people, particularly if there is any whiff of unfair business practices.

Ironically, while this accelerated feature delivery is partly enabled by continuous experimentation practices, that same speed of change can itself interfere with feature experiments. It can be difficult to statistically correlate an uptick in a KPI with a feature experiment when there are other changes happening over the course of the experiment.

Enhancing the observability of your software—the quality of logging and other instrumentation—is one key way to mitigate some of these challenges. Another is keeping the number of active feature flags reasonably low, which can help on a variety of fronts. It reduces the testing burden of multiple interacting flags, as well as the risk of experiments interfering with one another. Fewer active flags also mean fewer things changing at once for your users.

Managing all feature flags in a shared system can help in understanding the number of active flags and avoiding interfering experiments. Centralized flag management also means you can batch up a set of feature changes into a single release, which helps avoid overwhelming your users with many small changes. A centralized system makes it easier for testers to see which flags they should expect to be in play within different systems, and how those flags might interact.

We’re entering an era that will involve a massive explosion in the rate at which we release new experiences to our users. Embracing this next stage in the evolution of product delivery can enable teams to move faster and with greater safety. But entering this brave new world requires us to develop new practices if we are to avoid the pitfalls of a post-release world.

— Pete Hodgson

February 11, 2019
Self-Service Integration: 3 Areas to Watch
Self-service integration is a priority—more enterprises are turning to it for help in retaining their customer base, delivering a delightful customer experience and making it easier to do business with. It has become a de facto standard for modern-day integration solutions. Enabling business users to build integrations strategically addresses a dire need to establish a smoother symbiosis between people, processes and technologies; marshal them in an order; and align them with business objectives.

This approach is taking root across digital economies, and more advanced self-service integration features have emerged over time, which means bare minimum features are no longer enough. Enterprises with basic integration capabilities face the same old IT issues they faced earlier with conventional development tools.

In this blog, we’ll take a look at three critical features of self-service integration capability that can help enterprises sharpen their edge:
- Business User Capability: Enables business users to develop integrations and helps IT to drive innovations. Business users get built-in constructs to build integrations with heavy coding and rollouts, while IT can monitor all processes and technologies in a B2B network and avoid potential IT issues. With this advantage, business teams can operationalize data without IT getting involved and reduce time to revenue.
- Any Data Conversion: Modern-day integration solutions offer AI-led data transformation capabilities to convert data between source and target elements. The solution uses past traffic for suggesting data mapping recommendations and further reducing the time that goes into mapping data. Business users get a single interface to map data between source and target elements. Moreover, they can convert multi-gigabyte data in different formats in few minutes, rather than months.
- IT Governance: Self-service integration provides a drift-to-drive approach for IT governance. IT teams can combine old and new enterprise information systems and set up a concurrent integration strategy to use them for best of advantage. Start-to-end integration helps IT teams to streamline governance and enables business users to expand B2B connectivity. Teams can connect with a universe of applications without heavy resources involved.
Factoring these three capabilities in the zero code integration strategy can help teams to improve efficiencies, reduce the IT cost and improve B2B data exchange. They can counteract IT challenges in the form of multiple sources of truth and IT silos in minimum steps.

These three capabilities can help enterprises in improving process, people and technologies across business. By using these capabilities, enterprises can acquire knowledge faster and interpret data faster. Physical and digital environments can be populated with heuristic methods. Enterprise networks can be connected for more openness, connectedness, intelligence and scope.

End-to-end data integration improves the analytics process and drives the decision-making process: Data can be prepared for complex operations without complex coding.

Additionally, with self-service integration, enterprises don’t have to train citizen data scientists for data integration. Data scientists can use sophisticated functionalities for processing data from multitude of sources, and can re-engineer every piece of integration for syncing data with extremely powerful edge devices. They can establish strong neural networks for setting up diverse and robust architectures. Such systems can be used for complex use cases such as biometrics optimization, personalized medicine, material sciences and more.

A self-service integration framework is more than an enterprise service bus (ESB) or SOAP web services integration model. it helps in driving IT innovation, keeping things flexible and reducing costs. Modern- day integration solutions deliver out-of-the-box flexibility and reusability for bringing together composite services and executing them in a particular order across enterprisewide deployments. They help organizations grow their B2B networks and add new partners, suppliers, services and sales and support channels.

Enterprise information systems today generate massive volumes of data. There is a tsunami of information distributed between different B2B networks. Today’s data is being generated in variety of forms and the workloads have become difficult to predict. This veracity—or the ability to handle uncertainty caused by incompleteness, inconsistencies and anomalies of data—is a major barrier to unlock audience intelligence and customer segmentation in high-density computing.

Coalescing around a self-service integration strategy around these features is important for enterprises. It can help them in decimating the constraints they face on the road to B2B data integration: IT complexity that steadily decreases the pace of business, and silos that make them difficult to work with and slow down time to revenue.

— Jitesh Banga
February 4, 2019
Developers: Key to the User Experience in a Multicloud World

It’s amazing how many applications behave as if the network is always available, bandwidth is infinite and latency is zero. While optimistic, this approach to applications is ultimately rooted in fantasy. As it stands, there is a major proficiency gap between application developers and the networks in which they operate—but this can’t continue as our world becomes increasingly multicloud. It’s time for developers to understand the inner workings of the network to close the chasm between applications and the network.

Ships in the Night to Star-crossed Lovers

For the most part, applications and the infrastructure on which they operate have little to no interaction. If you’re not sure about this assertion, try asking any network operator what applications are running on the network. It’s possible they can tell you about key mission-critical applications, largely because at some point the person has had to troubleshoot an application issue. But beyond the top few applications, it’s likely that they are considered largely nameless bits and bytes that fill up wires.

Similarly, if you ask an application developer to explain anything about the network, you are likely to get blank stares. Yes, developers are aware that the network provides connectivity to critical applications resources, but it is atypical for them to know much beyond that. The acronyms that make up a network engineer’s livelihood are largely just jumbled letters—a bit of a nod to the dark arts required to actually make networks work.

This missed opportunity has the potential to be the perfect match. There have been various efforts over the years to bridge the gap between these worlds with movements such as application-aware networking and the somewhat lesser-known network-aware applications. The central thesis of these approaches is: The more these two co-dependent but largely separate organisms know about each other, the more they can adapt and adjust to deliver a superior end user experience. To achieve peak usability, each side must know something about how the other operates.

App Developers, Meet the Network

While technology is making networking more interesting than it has been in years, excitement about the network is largely contained to those directly involved in designing, deploying and maintaining it. This is no fault of anyone, though, because the main appeal of the network is that it remains essentially invisible to the user. The network is a success when you don’t know it’s there.

Consider the network as a power grid. When you turn on a light switch, you’re not concerned with how power is generated and distributed—you only care that it can light up the room, and you are concerned when it won’t. The physical infrastructure that makes this all possible is largely hidden to users and visible only when something goes wrong. Just as physical infrastructure is invisible, the network should be, too.

That said, it is important for application developers to “see” the network and not let it fade into the background that same way that users do. Awareness of the network and its functions is critical when developing applications that will run on this system, as simply invoking an application should also include the requisite infrastructure.

Broader Network Shifts are Required

Of course, no change happens in a vacuum. Application development must be considered alongside the broader industry move toward distributed workloads and the proliferation of multicloud, as it is increasingly likely that applications will be hosted in different environments.

Application developers need to not just understand the network, but also the different contexts in which that network exists. For the infrastructure to be invisible, this means those different environments—on-premises, in public cloud A or in public cloud B—must deliver the same experience, inclusive of both policy and security. This creates a bit of a challenge if the future is to be a tight mesh of interwoven applications and infrastructure. For a group that today assumes 100 percent availability and infinite bandwidth, this would be a pretty massive shift in thinking, and a correspondingly massive additional burden to bear.

Abstraction is the Answer

In the same way that containers serve as an abstraction above the compute environment, there must be a level of abstraction that sits above the cloud environment. This is really what underpins the multicloud movement.

Application developers must ensure that application requirements are agnostic to the underlying infrastructure to ensure the system remains invisible to the user. Likewise, multicloud management must create an abstracted platform capable of translating application intent into device behavior regardless of where that device resides, whether it is physical or virtual, or even whether it is from vendor X or vendor Y.

Taking on the Future of Multicloud

Much too often trends in IT favor silos. As we make the shift toward multicloud, networking will be brought into focus like never before, requiring a different way of thinking about cross-domain management. What is required from application developers and network operators alike is communication and collaboration.

Having a baseline understanding of how the distributed network functions will allow application developers to create products that will ultimately run better. Developers should also be transparent about what they are expecting from the network and what they need. This is the only way to get us closer to where we want to be: operating on a network that is omnipresent and wholly capable of anything we can throw at it.

— Mike Bushong

December 6, 2018
What Developers Can Learn from Apple’s iOS Woes

Apple’s decision to delay new features in iOS to address performance and quality issues is a setback for the company, but it also holds valuable lessons for software developers and dev teams about the environment we work in today.

A recent report said Apple plans to pull back on several new iOS features until next year, including a refresh of its interface and improvements to core apps such as mail. It’s an uncharacteristic move for Apple, and follows a wave of criticism over a number of security and quality issues in recent months.

Apple’s missteps come against a backdrop in which companies are under more pressure than ever to get new features to market quickly. It reveals just how intense that pressure has become—and the problems that can result if companies get careless or try to move too fast. Dev teams must learn to navigate a delicate balance between speed and quality.

Here are four takeaways for dev teams from Apple’s decision to delay features in iOS.

The Pressure to Ship Fast Has Never Been Greater

The tech industry is going through a startling period of innovation, with smart assistants, augmented reality, biometrics, wireless charging and host of other technologies all entering the mainstream at the same time. The fact that a company like Apple felt sufficient pressure to push features out before they were ready is a sign of just how intense this pressure is. If Apple was famous for anything, it was quality; the company never released anything until it was rigorously tested and perfected. This has been changing for some time under Tim Cook, but Apple has never felt quite the pressure that it has lately. While not all dev teams are pushing multiple bleeding-edge technologies simultaneously the way Apple is, it’s a reminder of the pace of innovation that we all need to design our pipelines for today.

Prioritizing Speed Over Quality Will Hurt You

While dev teams need to move fast, they can’t afford to sacrifice quality for speed. Every company must make careful trade-offs between the need to move quickly for competitive reasons and the need to get it right. Moving too slowly can allow a competitor in the door, but moving too fast can diminish quality, drive users away and create the kind of backlash Apple is now seeing. Developers need to learn to make this difficult calculus balancing quality and speed. And quality isn’t just about bugs; it’s everything. Ease of use, design, build—these are all elements of quality, and they must all be factored into the decision of how fast you move.

User Experience is Everything

The industry continues to evolve toward better usability, with more energy being invested in creating easy-to-use, well-designed user experiences. In a world where your customers can easily switch their smartphone and the applications running on it, good design in technology is imperative for keeping users delighted and engaged. It’s gone from being a nice-to-have to an essential feature.

Developers Should ‘Shift Left’ for Higher-Quality Code

Traditionally, QA has gotten involved toward the end of the development life cycle. But when you move quickly, code can suffer and you end up shipping features that could do with a bit more work, as Apple apparently has. By “shifting left”—or testing earlier in the process—any issues are easier to fix. Why? Because slower feedback cycles create distance from the problem. Developers become forgetful and shift to other tasks, which means they lose context. Additionally, code can change, which complicates the process of fixing the problem. Testing earlier surfaces errors more quickly, tightening the feedback loop between QA and development.

We don’t have details about what happened inside Apple, but it appears the company is having to slow its release cycle to fix quality issues that weren’t identified the first time around. This is a danger for all companies that are trying to keep pace with the latest technology trends. Developers need to think about all aspects of software quality, ensure their pipeline can accommodate the pace at which they work, and avoid shipping bugs into production that will come back to bite them later on.

— Fred Stevens-Smith

February 13, 2018
Survey Finds DevOps Teams Under Increasing Pressure

The fact that a much larger percentage of companies now recognize they are software companies that happen to specialize in a specific vertical industry is now putting a lot of pressure on developers, according to a new survey of 750 development team leaders in the United States and the UK conducted by Testplant, a provider of tools that automate application testing.

The survey finds that 42 percent of the respondents claim they are expected to design, develop and test apps in an unrealistic amount of time. More than one-third (36 percent) also report they are not given enough time to ensure apps are properly tested before deployment, while 56 percent note that use of outdated techniques and tools is holding them back from meeting the demands of the digital world.

Because of this combination of factors, nearly half the respondents (49 percent) say they are deploying applications before they go through an ideal testing amount of testing, and 45 percent admit to putting applications into production that will perform below initial requirements.

Dr. John Bates, CEO of Testplant, says it’s a matter of time before IT organizations will have to rely more on tools that automate much of the testing process, as pressure on DevOps teams to roll out new applications and update existing ones is only going to increase. The survey respondents (60 percent) say most of the pressure to accelerate software development is being driven from within the organization itself. But nearly half (49 percent) say pressure comes from competitors. As more organizations realize their competitive differentiation comes from the software they develop, there’s now a lot more focus on accelerating application development, says Bates.

The survey also notes that the applications being built are more complex than ever. Over the next 12 to 18 months, half the respondents (50 percent) say their company will develop more apps using components for an internet of things (IoT) environment. Well over half (58 percent) also say their company will develop more apps with artificial intelligence (AI) components, and 62 percent say their company will increase the amount of applications that incorporate machine and deep learning algorithms.

When it comes to deploying applications, automation is ranked as the most critical challenge by 67 percent of the respondents, and 70 percent claim they are now more focused on automated testing today than they were in the past.

In total, 75 percent of the respondents say that with access to better tools, the applications deployed by their team would have a greater impact on the business. A full 81 percent also say that with more time, applications deployed by their team would have a greater impact on the business.

Unfortunately, more time for application development is luxury most business don’t have today. Not only is a wave of digital business innovation is making it easier for startups to not only enter markets, but companies that traditionally have focused in one market segment are now extending their reach to adjacent areas. The difference between surviving and being made obsolete now comes down the level of customer experience an organization can deliver by the applications it makes available to customers.

Unfortunately, when it comes to those applications, customers tend to be unforgiving. Once bad application experience and many of them will move on to try an application developed by a rival. Bates notes that too many organizations still seem to think they can test their applications on end users on the assumption they can fix any issue that comes up rapidly. In reality, rather than participate in what amounts to an extended beta testing process, most end users will simply look for a better alternative application experience.

In short, the difference between success and complete failure now hinges on the level of quality application testing that can be implemented in the shortest amount of time possible.

— Mike Vizard

November 2, 2017
Testing’s Role in Delivering Digital Transformation
“We have a quality philosophy now…but it took the rise of the middle child to make it happen.”
- Ann Lewis, ExxonMobil
Ann Lewis’ metaphor of testers being the “middle child” between software development and IT operations was present throughout Accelerate 2017, Tricentis’ annual user conference. Nearly every head in the room nodded as Lewis described how testers, like middle children, tend to get less attention than their professional or familial siblings, but she insisted that there’s never been a better opportunity for testers to receive the respect they deserve. Digital transformation, no matter how you define it, requires new commitments to quality, and it’s up to testers to claim be the change agents in the transformations that CIOs are tasked with delivering.

Tricentis CEO Sandeep Johri and other CxOs who spoke at Accelerate echoed this sentiment. Johri pointed out that speed continues to be a primary focus of maintaining or gaining competitive advantage, and manual testing processes that prevent agility or DevOps success at the enterprise level must be automated going forward.

What was also made clear is that scaling investments in automation is not the single key to success. The pressure CIOs are under today, especially around digital transformation, requires new investments in a number of different areas, many of which are only just being realized. While CIOs may understand the necessity of quality, it’s up to testers to get the buy-in required for the continuous testing required to deliver it at scale.

Testers with an oft-ignored middle child mindset may find the concept of being recognized as a “champion” by their CIO or CEO unlikely. But, Todd Pierce’s impassioned session on “What CxOs really think about testing” was designed to inspire testers to change the way testing was viewed too often in the past.

As a current Rock Health and Dignity Health board member, and former Bill & Melinda Gates Foundation chief digital officer, Pierce shared his peers’ all-too-common beliefs that testing takes too long, costs too much and constrains developer productivity. And, while it may hurt to admit, with manual testing that should be automated and insufficient testing time that results in bugs making it to production, it’s not surprising that CIOs would feel this way.

Pierce explained that testers who adopt innovative, scriptless “high-precision testing,” are able to shorten their test cycle, reduce defects that make it to production and eliminate costly rework for themselves and developers alike. When high-precision testing is performed continuously throughout the software development life cycle (SDLC), those beliefs that testing takes too long, costs too much and impedes innovation lose all validity. “Everyone in this room should be the drivers of agility in the enterprise,” remarked Pierce.

Emmet Keeffe at Insight Venture Partners hosted a CIO roundtable later in the day where four CIOs detailed their personal experiences with taking enterprises through digital transformations. Each CIO admitted that in the past they had underestimated the the time being spent on testing, and one somewhat bravely stated that he’d always found testing somewhat “boring.” One might expect a room of testers to storm the stage with charges of heresy, but, given that many testers have suspected that management felt this way for years, I got the feeling that many were simply impressed that someone who felt that way had admitted it.

But the panel, Pierce, Lewis and countless other speakers at Accelerate also made sure that the attendees of their sessions understood one thing: As more organizations undergo digital transformation—and no matter what stage of digital transformation they’re in—testing has never been in a better position to drive positive changes that will have monumental impacts on the business.

Whether CIOs have been tasked with delivering greater agility, DevOps shifts, increased security, enhanced user experience, reliability and performance or legacy app modernization, testing may not be the first organization that CIOs turn to for help. But, as Keeffe explained, testing leaders who truly understand the incredible opportunity they have to make those CIOs heroes will make themselves heroes in the process.

About the Author / Noel Wurst

Noel Wurst leads influencer relations for Tricentis, and collects stories around cultural shifts and evolving technology’s impact on the software testing industry. By attending global conferences, interviewing passionate software professionals, and working closely with product, engineering and customer success teams, Noel looks for stories that matter and innovative ways to share them with audiences that lead to business growth. You can follow Noel on Twitter and LinkedIn.
October 30, 2017
The Emergence of UI and UX in DevOps Tools
Most of the popular DevOps tools on the market such as Puppet, Chef and Jenkins, are open-source and require a high level of proficiency. With the complexity comes the challenge of learning new frameworks and paradigms, a benefit to those who want to challenge themselves and learn new skills.

But while these tools have become widely adopted, the widespread adoption of DevOps is creating a need for interfaces that cater to all users, from the most technical engineers to those who don’t want to learn, don’t see the value in learning or don’t need some of the top-end power that a complex scripting interface provides.

It is for this reason that CloudBees developed Blue Ocean, a new interface for its continuous delivery tooling, and Red Hat released a user interface (UI) for Ansible.

The Right Time for UI?

Why have there not been UIs before now?

I would say two reasons:
1. Users did not demand nor care for one until now. A UI in many circles is seen to been more presciptive/restrictive of what can be achieved, and that only scripting/programming interfaces expose the real power to an engineer. Also, many of the most progressive engineers like scripting; they derive satisfaction from learning new skills, especially those that are the most highly desirable/in demand. And, I think many engineers like things because they are difficult to do; it’s a challenge, they have bragging rights and means they likely are getting paid more/are in demand.
2. The open-source community is not as good at or geared toward building UIs.
Why has a UI become important now?

At MidVision, like many of the other commercial automation tool vendors, we have always believed that user experience and accessibility is critical, so we have provided command-line, scripted, API and GUI interfaces to our tooling. But this has not been the common approach.

What makes this moment different is the wider adoption of DevOps automation tooling by groups that want at least graphical user interfaces (GUIs) and improvements to user experience such that you don’t need to be super-technical to be able to use them.

The main groups we see are:
- Business users within an organization. Continuous delivery/release automation tooling very much promotes collaboration, interaction and self-service, allowing release managers to see the status or pipelines, approve releases or initiate deployments. Managers may want to see dashboards and metric, produce reports or usage data. Other less technical staff, offshore teams, second level support, etc., may want to be able to provision, clone environments or deploy changes.
  There is a gap between the nerds in the basement speaking one language – and the business users who speak another which accessibility, UI and UX hopes to bridge.
- Operations. There are certain parts of IT Operations that have welcomed the technical script-based tooling with open arms—it was a natural evolution for a UNIX system admin to become a DevOps/automation engineer. They can still script in shell (or are they meant to be doing it all in Python? ?). Again, some of the security tooling, storage, etc., are generally more comfortable down in the weeds. As you move up the stack however, toward the business application deployments, users are much more familiar and comfortable with UIs. Also, at this level dashboard, metrics, access control and reporting are much more important—and all of which are very hard to achieve without a proper UI.
- Wider industry adoption. Adoption of the tools and techniques that are often advocated in the DevOps world started with the same poster child companies—Netflix, Twitter, Facebook, Google—and other newer companies that are cloud-native, have an open-source-first policy and are unencumbered by heritage technology stacks.
We have then seen parts of enterprises adopt DevOps practices and tooling. Obviously, it is important to start small, establish value and then scale—running an initiative like you would a startup within an enterprise works well.

Now that there is a compelling body of evidence to suggest that DevOps practices provide competitive advantage, cost savings, improved time to market, etc., other industries that are heavily dependent on technology have not had yet adopted these practices for varying reasons. Some parts of the finance and healthcare industries are two such areas. These industries have concerns around security and stability that may have slowed their adoption to date.

Overall, however, this wider adoption means we need to cater not just for the new breed of DevOps engineers that are both system administrators and programmers and can script in Shell, Rudy and Python. We also need to cater to a wider group that either don’t have the skills to use these tools or don’t care for them.

What change, then, are we likely to see?

I believe DevOps tooling will evolve to provide new interfaces to cater to business users and self-service, and to make it easier to achieve the same thing without needing years of experience using a tool before being considered a competent user.

I would compare many of the current tools today to a map and compass. Lovers of orienteering or mountaineering may suggest using a GPS or map on a mobile phone is cheating, cannot be relied upon or won’t provide the same same information as the contours on a 1 to 10,000 map. Or maybe you prefer vinyl to Spotify.

Neither of these things are wrong; they are just not the only right. If you want to nerd out with your map and compass, vinyl LPs and Python scripts, I say fill your boots. All of which, BTW, I have some passion for! However, if you also want to get in your car, enter a zip code and know that it will get you there (accepting there is maybe a route that is slightly quicker if only you had done your research more thoroughly), this makes perfect sense to me.

User experience is at the heart of the most of the other products we choose to consume, and I think many new and existing users will be pleased with UX becoming more important as tools like ours and others put this at the forefront of their design.

About the Author / Dave Sayers

Dave Sayers is a co-founder and technical services director of MidVision, a provider of Release Automation and Continuous Delivery Software. He works closely with customers and partners on DevOps and Automation initiaitves throughout Europe and North America and is responsible for devising and managing the partner and channel strategy. Connect with him on LinkedIn.
May 30, 2017
How Healthy is Your Office 365 Environment?

The IBM Domino environment was mostly replaced by Microsoft on-premises technology, then later replaced by the Microsoft Cloud Services. One thing that hasn’t been replaced is the need for administrators to have control and visibility of service delivery to end users.

Whether you’re using IBM applications, Microsoft on-premises servers or Microsoft Office 365, as the messaging administrator you need to provide availability and performance metrics of the service delivered to your management. You also need to understand issues when they arise.

In short, you are still responsible for the service that you deliver, even if the servers reside in Microsoft’s data center. So, how do you measure the health of your Office 365 service delivery and how do you anticipate issues before they impact your end users?

Measuring Office 365 Health

Microsoft works to maintain the 99.99 percent availability it promises from its data center as well as improve both the features it provides and the performance it delivers. The issues that arise generally impact only some features and usually only affect a subset of users with a specific configuration or in one location. It’s difficult to know exactly how these issues impact your global network, and it’s impossible to predict, but it helps to know that Microsoft offers a health dashboard. The dashboard provides an easy-to-understand view of the availability and performance of each Office 365 service out of the data center, and lets users configure alerts. The disadvantage is that the dashboard only shows service out of the data center, not any visibility into the service your users are experiencing. It also doesn’t provide information on how issues are impacting the availability and performance in your company. Nor does it take into account user complaints that can stem from many issues within the Office 365 environment.

Microsoft provides two tools that can be useful for measuring the health of the Office 365 services delivered to your users. First, the Remote Connectivity Analyzer allows you to run a series of checks from the cloud to the cloud that will tests different part of the Office 365 services. This allows you to check if your tenant has problems with the basic functions of Office 365 by running Outlook connectivity tests, opening a mailbox, performing a mail routing or connecting to Skype to Business Online. The disadvantage is that it is performed from Microsoft Azure to Microsoft Office 365—from one cloud to another. It doesn’t provide you with any information that could help you troubleshoot what is happening at the user location.

Microsoft’s other tool that can be useful when it comes to checking the connection is the Support and Recovery Assistant. This tool lets you perform tests to help you understand what’s happening when a location is experiencing poor Office 365 performance. However, these tests aren’t automatic or continuous, and they don’t alert you when an issue begins to arise. You still have to rely on user complaints for that.

That leaves manual testing as the last option for administrators. Manual tests are available in PowerShell. When conducting tests, start by testing pings to Office 365, DNS resolution time, latency and end-user egress points to understand the impact of the network on your Office 365 service delivery.

Even if these tools are not enough to measure, alert, report or troubleshoot the service to your end users, they still provide something to check the health of the Office 365 service. Microsoft understands that the service out of the data center is not what matters most; it is the user experience. That is why when people think about their Office 365 health, they should always consider the entire service route, from the Microsoft data center to the user sitting at his desk.

When we measure health, we understand availability and performance of the service.The border between poor performance and unavailability is small, especially for end users. To understand the health of your services you need metrics, facts and alerts.

What really matters is not poor performance but a degradation of the performance, because that is what users perceive. To measure performance degradation, you need to know the baseline, or what’s normal. This requires a tool that continuously measures the performance delivered to your end users and that can alert you when the performance is declining.

Finally, because most Office 365 services are used in conjunction with internal infrastructure applications and appliances, they also can impact the service delivered. If you don’t monitor these applications at the same time and on the same dashboard, you won’t be able to troubleshoot the issue effectively. Some companies have hybrid Exchange, some still have Domino application servers, some are using gateways, some have proxy servers and so on.

It all comes down to service delivered to your end users. Whether issues arise from the data center or your network, it’s important to monitor and understand what users are experiencing so you can maintain the highest level of service. Understanding the relationship between availability and performance from the user’s perspective helps you achieve better insights and oversight of your cloud or hybrid cloud health.

About the Author / Jean-François Piot

Jean-François Piot is vice president of Product Management at GSX, responsible for articulating the vision of the company’s product range and translating these into detailed specifications. His experience in IT processes and service management projects comes from previous business development positions at IBM and Beijaflore (IT Service Provider). He holds a master degree from the Grenoble Graduate School of Business.

January 11, 2017
Adding Usability Testing to the CD Pipeline

Do you include usability tests in your continuous delivery pipeline? If not, you could be making a big mistake.

Usability testing, which entails having actual users test an application for user-friendliness, intuitiveness and accessibility, gets easily lost within the DevOps conversation. If you want to do continuous delivery, waiting on manual usability tests may seem like a major barrier.

Why Usability Testing Matters

Yet, DevOps teams that ignore the importance of usability tests do so at their peril. Continuously delivered apps will provide little value if they are difficult for ordinary people to use. Users have little tolerance for applications that lack usability.

It’s worth noting, too, that DevOps makes usability testing even more important than it would be within a waterfall delivery chain. When you do continuous delivery, your software changes more quickly. That increases the chances of introducing a change into production that negatively impacts app usability.

How to Do DevOps Usability Tests

So, how can you do proper usability testing without slowing down your continuous delivery pipeline? Unfortunately, there’s no easy solution. Unlike integration and unit tests, usability tests cannot be easily automated.

You can, however, work closely with your in-house QA team to perform usability tests before changes reach the production stage of your pipeline. This will work as long as your QA team is able to replicate real-world usability conditions well.

Alternatively, you could release changes to a select group of users before making them generally available. Those users would then test for usability issues quickly and report them to you before your updates reach the wild. This scenario would essentially mean doing a very fast beta release for certain users. If that seems unfeasible, keep in mind that, as long as each of your continuously delivered changes is minor, quick beta testing is manageable.

Whatever you do, the most important thing is to avoid ignoring usability testing. Otherwise, all of the hard work you put into continuously delivering your app could be for nought.

— Chris Tozzi

November 29, 2016
Don’t Leave Software Testers Out of DevOps

The term DevOps implies that software delivery is all about integrating the development and IT operations teams. But the software testing team is an important, if oft-overlooked, part of the picture. Here’s why.

Could you deliver software continuously without involving the QA team in the continuous delivery pipeline? You could try, but it would probably not go well. Software testers play a vital role in continuous delivery, for the following reasons:

They are the glue connecting developers to IT Ops. If there is no one to test the code that developers write, IT Ops cannot deliver a stable product.

They help find problems before they become costly. If you skimp on integration, unit and performance tests, you won’t find problems in your software until after it reaches users. By that point, fixing those problems will be much more time-intensive than it would if they had been caught early on. Plus, your organization’s reputation will have taken a hit, because problems that could have been nipped in the bud prior to delivery ended up affecting users.

They know things that developers and IT Ops don’t. If DevOps is all about continuous visibility across the delivery chain, then it only works well when the delivery team’s collective expertise covers all parts of the delivery process. Since developers and IT Ops people are not experts in quality assurance or testing, you need to involve testing professionals in the continuous delivery chain so that they can help everyone else understand the parts of the process that QA professionals know in detail.

All of the above is to say that if the QA team is not plugged into every stage of the delivery process, your software either won’t be tested efficiently, or it won’t be tested at all. Not testing efficiently means that the QA team is not in sync with the rest of the organization. In this case, the QA team would delay software delivery because it would have to wait on developers and admins to complete its work, and vice versa.

Not testing at all, of course, is even worse. No one should deliver unvetted software to users.

Don’t Forget about QA

The takeaway for organizations seeking to adopt DevOps practices is this: Even though the DevOps conversation on the surface may seem to be about only developers and IT Ops professionals, QA teams play an equally crucial role in continuous delivery. They need to be as involved in the continuous delivery pipeline as everyone else if an organization wishes to reap the full benefits of DevOps.

— Chris Tozzi

November 8, 2016