Keeping up with DevOps

Source – techrepublic.com

Waterfall program design was first described in 1956. It continues to operate today in companies because of the volumes of legacy software that IT still supports. Waterfall is also an excellent, step-by-step software development methodology that has proven itself for decades.

The methodology is named waterfall because application development flows only one way: downward, like a waterfall. Waterfall development begins with requirements definition, moving down into design, then programming, test, and implementation.

In contrast, DevOps, which can approach all of these phases in a non-linear, near-spontaneous fashion, is still a nascent software methodology. A Statista 2018 survey revealed that only 17% of organizations had fully adopted DevOps. There are also reports of DevOps failing in organizations, primarily because organizational alignments retained their traditional forms and didn’t evolve into the type of multi-disciplinary work groups that were optimal for DevOps. The other problem is DevOps testing, which must be continuous if you are continuously modifying DevOps apps

Application developers, whether they work in DevOps or traditional programming, are seldom fond of testing. What they want to do is shortcut testing and deploy applications faster. Unfortunately, the horror stories of not thoroughly testing apps before deployment are too numerous to mention, and can be real career threateners.

Check out the tips below to see how can you ensure the success of your DevOps apps without sacrificing quality and other hallmarks of excellence that have made waterfall software design so successful.

1. Focus on time to market automation

If you’re going to adopt a DevOps methodology that requires near-simultaneous development, and testing and deployment of apps that dramatically improve your time to market, you need automation tools that can speed up the process. There already are tools for rapidly developing application prototypes where users enter data and test navigation.Tools that allow you to automatically deploy virtual instances of operating systems for test also exist.

Now there are testing tools that automate the check-out of a new app on a plurality of different devices and appliances.

“What we want to replicate is what end users do,” said Shoeb Jared, CTO for Worksoft, which provides test automation tools. “With automation, we can test 60% to 90% of applications, although there are still manual parts of business operations that can’t be tested by automation.”

2. Get the right DevOps teams in place

DevOps doesn’t work well when IT is deployed in traditional departments like application development, operations, infrastructure, networks, database, and QA. Because all of these activities can go on simultaneously with DevOps, the DevOps team should be an interdisciplinary group that includes all of these functions. The team need end users, as well.

If you don’t have this interdisciplinary team in place, you will have a hard time succeeding with DevOps. It’s equally important to recruit the right types of personnel for DevOps teams, whether they come from IT or end user areas. DevOps team members should be collaborative and team-oriented.

3. Demand quality testing

Taking shortcuts on testing is a waterfall as well as a DevOps programming problem. By nature, application developers don’t like to test. When they are up against a deadline, they also tend to view QA (and QA functions) as impediments to completing work.

DevOps test tools help automate testing at multiple levels: field edits, ergonomics, database and system routine access, stress testing, integration testing, etc. These tools can even test an app on multiple devices. However, in other cases, such as complicated middleware interactions or highly complex database access, manual testing works best. The DevOps manager (and team) must determine the best testing mix.

4. Insist on documentation

Like testing, documentation is another area that programmers dislike.

There are automation tools that capture logs and issue alerts. They can be combined with test scripts to produce more complete documentation, but some of the same “black box” or undocumented code that haunts waterfall applications also exists with DevOps. For instance, you seldom get a meaningful summary of the app’s overall purpose and functionality. This can make it difficult for follow-up madevops.com/continuous-documentation intenance, because the maintenance programmer doesn’t have a full sense of the app, which makes it harder to fix or enhance.

5. Use DevOps for internal company applications—but avoid using it for outside customers

DevOps is a fluid, continuous and highly creative application development process. DevOps can also be highly experimental. For this reason, it is best to deploy DevOps applications internally and not with your end customers, who could get disrupted if there is too much application change.