You know what’s scary? DevOps. The culture shift, the constant collaboration, the new sets of tools — it’s quite a lot to handle. Everyone’s looking for the coveted smooth-running software development pipeline.
Virtualization has been around for a long time. As early as the 1960s, IBM was supporting virtualization on mainframes to ease the cost of migration among multiple generations of their systems. Languages like Pascal, Java, and C# translate into virtual machine languages that are then either interpreted or further compiled (“just in time compilation”) into actual machine code.
Just when you thought you were safe from more process improvement for a while-not so fast. There’s DevOps, Continuous Testing, Continuous Delivery and Continuous Deployment. In this issue, we are focusing on Continuous Testing, the part most concerning test teams.
This article was originally published on DevOps.com
It wasn’t long ago that the Dev and test teams would work late hours, focused and rushed to meet a deadline: rapid fixing, reprioritizing and deferring bugs to close out the bug list, move everything to the staging server, do one last run of the regression and pass it over to Ops/IT to move to production. What happened after? No one knew. For most Dev and test team members, Ops is a black box. More often than not, they are oblivious to what happens at Ops, the roles, responsibilities and timelines. One day—long after the drop-dead deadline for Dev and test teams—after delays, questions and changes, the product went live. Continue reading