The hyped mnemonic “DevOps” is equally true the other way around: OpsDev – that is, more and more work in the operations and infrastructure departments happens as development activities with scripts, code repositories and build managers. OpsDev is as tool-heavy as DevOps, and test involvement similarly pipeline focussed.
With Docker and similar tools, system administrators no longer need physical or desktop access to the machines and equipment in order to push out profiles, but can just use scripts. With scripting comes source repositories like GitHub and gitlab. With git comes the package and build engines like Jenkins with Maven. You can manage your Docker environments with continuous integration. Like Laszlo – they remind me that test environments are no longer permanent; all environments besides production can be temporary based on the latest branch and build (in many contexts).
At work, we have a central software tool that can schedule maintenance tasks on all server types. The orchestration can handle the pushing of a configuration to a network card, push an OS-update and backup profiles. Patch management and middleware updates are no longer tedious task, but scheduled and build-schedule-run through server orchestration. Operational orchestration reminds me of the eTOM notion of order fulfilment, order provisioning etc. The vocabulary is from the telco domain of loading profiles and configurations on switches and routers – which is not that different when you think of it looking at network equipment like iron ports, load balancers and Citrix jump stations.
OpsDev is all about using CI/CD to perform tool-assisted deployments fast. Test environments are a great starting place. In the operations department, their work covers all environments – test or production. Differentiating between virtual or temporary isn’t that important anymore. Integration level testing might be established within LAMP environments or within a certain cluster or virtual LAN segment.
With more and more test environments in play, there is a need to manage test environments, to share configuration information, who is using the environment and for how long. A tool that has its unique value proposition in doing just this is Plutora Environments – it excels in providing test environment management including:
These features include impact matrices, visualizations and concise reports for all stakeholders. With Plutora Environments in the cloud, there is no need to manage this in spreadsheets, SharePoint or outlook calendars – especially since Plutora Environments integrates to other ITSM and test management tools.
Testing in OpsDev is inherently “shift-left” based on the scripts and the test environments on which the scripts run. Still, similar to DevOps – testing can happen everywhere. Testing scripts in OpsDev can confirm and check that the profiles have been pushed and servers and services available. As these checks are based on existing technologies and on reliable COTS solutions, it’s usually sufficient to just check it. Challenge testing like whether or not a disk can hold a certain amount of bytes is usually not executed. Testing on an OpsDev level tells nothing about the fulfillment of the customer’s needs – unless this is the continuous maintenance of her servers.
Test management in the OpsDev space is all about setting up a framework/process for the technicians to follow with regards to build gates, orchestration and the quality in the delivery pipeline. Test management in “shift-deliver” mode is all about providing the overview of delivery progress to management and giving it the needed narrative.
The narrative of OpsDev is a funny little twist that illustrates that there are other places in IT delivery that uses the tools of software delivery and similarly can benefit from some structured testing activities and tool support – we might as well get involved.
The post DevOps is cool, but get involved in OpsDev for Test Environment Management too! appeared first on Plutora.