“DevOps promises speed: delivering value to customers, reducing cycle time, faster time to market, shorter mean-time-to-resolution.” Speed is only one of the many benefits of DevOps highlighted in a recent survey of IT executives conducted by the editors of DZone.
Much has been written over the past 20 years about how Agile and DevOps can provide significant benefits for organizations that adopt these principles. And while the drive toward Agile and DevOps may be an imperative for your organization, you may be struggling to make real progress toward your goals. Paragon has made significant advancements in this area and has also engaged with many organizations who have just begun the journey or who have struggled to get started.
In this three-part blog series, we share a Q&A session with Mark Medlin, Paragon’s chief technology officer and co-founder, and Eric Bergemann, Paragon’s director of product development. The two discuss the industry’s transition to DevOps and continuous testing and deployment, and why this shift is a strategic imperative. Over the next three weeks, the conversation will cover what Paragon is seeing in our clients’ journeys to DevOps, common challenges organizations face and tips for how to overcome them, and the importance of testing.
How have testing processes changed at Paragon with the drive from Waterfall to Agile and DevOps?
EB: At Paragon, we've been using Agile as our development methodology for over a decade. We have been using test-driven development as well. While the drive to DevOps has been more recent, Paragon has leveraged continuous integration and continuous testing for a while.
The reasons we made the move to DevOps are the same as for any other organization. We wanted--needed--to deliver our products to the market more quickly, reduce costs, improve accuracy and provide better customer service.
Enterprises competing in an increasingly digital economy must simultaneously improve performance on four levels. They need to increase speed to market for customer-facing products, improve flexibility in business-supporting capabilities, boost product quality, and raise financial performance. Agile and DevOps practices are critical to achieving these four goals and to maintaining competitive resilience.
MM: Of course, every customer journey is unique. There is no single answer for DevOps, no silver bullet. So as each organization progresses down its path, we want to make sure that we can provide the tools, resources and expertise to help them be successful. Timing is a critical factor here. We recognize that every company cannot move at the same speed. We need to be able to support both early adopters of technology, as well as more conservative organizations. For example, we are currently delivering new functional releases every 2 weeks, but our release methodology allows customers who cannot consume change that quickly to skip one or even several release cycles with no negative impact.
Would you say that most organizations have made the move to DevOps in the past five or six years?
MM: As noted before, this varies client to client. Some have certainly moved more quickly than others. What it really takes is for an organization to be committed. Cultural change is a critical success factor for organizations moving toward DevOps. One isolated person or even one group in the organization can’t make the push alone. It usually it takes a senior executive sponsor within an organization who recognizes the key benefits to moving to a continuous deployment/DevOps model.
Are there any generalities, like larger organizations tend to be more open to it or smaller organizations taking a little bit more time? Anything else you notice in terms of trends of willingness to embrace the approach?
MM: A larger organization is going to have more resources to put behind it, and they're probably going to make more progress than a smaller organization. Smaller organizations, while they see the benefit, sometimes don't think they have the resources to make that change because it's a big shift. But any organization that really wants to can start making the change. You have to start somewhere. We recommend starting by automating one small piece of the testing environment, get some runs on the board and then look for the next little piece. It's all about automation when it comes to DevOps and testing is a big part of it.
On the other hand, some big companies have so many existing manual processes that they need to revamp their systems before they can move toward an automated process. Organizations that have been around a while will naturally have a longer history of doing things a certain way, so even though they might have a lot of resources it can still be a daunting task to move to DevOps.
In some cases, you'll see some smaller organizations that are younger and can move a little faster because they don't have the weight of the past bearing down on them. It varies from organization to organization how well they can move along.
Are there any common mistakes you've seen organizations make when they're first trying out DevOps and taking on the new approach?
EB: From our experience, the main thing we see is testers who are not in tune with writing automated test cases. The testers and the people writing the test cases need to work together, and it needs to be a collaborative effort. If you keep operating in silos with one group running manual tests while a different team builds new automated tests, you’re not only going to have gaps in your testing process, you’ll never realize the accuracy, efficiency, and coverage of a comprehensive test library.
It's much more efficient if the testers are involved in the test writing--ensuring you've got the right test cases and specifying the test cases that need to be there. They should also be involved when new features are being developed and coded because they can provide a lot of great feedback to the developers, bringing up things the developers may not have thought about.
Having a lot of brain power focused on all the ways you might “break” the software is critically important to the overall quality of your products.
Software testing is a key part of the Agile+DevOps life cycle — 72% of firms say testers are critical to continuous delivery success. To this end, more mature firms are transforming software testing to become continuous testing by implementing new testing best practices.
What resources are needed with this shift? How many people and what departments need to be involved first?
MM: If you’re starting from nothing, we recommend beginning with the testing, as we did. We made the decision to automate testing first because we saw this as one of the bottlenecks that we needed to correct to get our own software deliveries out the door quicker.
We also began using test-driven development. When we wanted to add a new feature or a new chunk of code, we built a test to prove the functionality and so that we would know (as Agile developers) when the task was done. When you start with the test, the software is initially going to fail the test. Then as you implement the feature through a series of stories and releases, the test is eventually going to pass, and you can move on to the next enhancement.
EB: A lightweight way for organizations to get started down this path is to get the developers involved. Most developers these days are familiar with the concept of test-driven development and are anxious to remove manual tests from the development process. The positive results here are cumulative. More automated testing will lead to improvements in accuracy, efficiency and productivity.
In the next post, we’ll look more closely at why Continuous Testing is a critical component of a successful DevOps implementation and consider some of the issues associated with legacy application environments.
If you’d like to explore how automating and integrating your payments testing environment can help your DevOps journey, contact us to learn more.
Mark Medlin is one of the co-founders of Paragon Application Systems and currently serves in the role of Chief Technical Officer. Mark has been instrumental in the design and development of Paragon's entire product suite, the introduction and implementation of Agile software development, as well as the drive toward DevOps. Mark is a graduate of North Carolina State University.
Eric Bergemann is the Director of Product Development and a Master Engineer at Paragon. He has been with the company since 2003 and has been involved with the design, development and support of Paragon’s Next Gen testing solutions since their inception. Eric is a student of technologies and processes that facilitate efficiency and quality in all aspects of the software development lifecycle. He has a degree in Computer Science from Campbell University.
Stay in the Know!
Check out our newsletter and stay up to date about the latest trends.