Tag: Z Open Unit Test

  • To Build a Healthy DevOps Culture, Look to Your Ecosystem

    To Build a Healthy DevOps Culture, Look to Your Ecosystem

    How do you do DevOps?  Here’s a hint: Don’t fixate on finding the right tools or implementing the right processes. Instead, think about the broader ecosystem in which you operate, the culture that prevails in that ecosystem and which parts of the culture you can borrow to help enable your DevOps transformation.

    This is true no matter which type of ecosystem you work in–even one that depends in part on mainframes. In other words, to quote from Rouan Wilsenach, writing on Martin Fowler’s blog, “Even with the best tools, DevOps is just another buzzword if you don’t have the right culture.”

    Keep reading for tips on what this means in practice, and how to build a successful DevOps culture by engaging your ecosystem.

    Tools and Processes in DevOps

    To be sure, tools and processes are a key part of DevOps. We’ve yet to see an organization that achieves continuous delivery successfully without the help of a continuous integration server or a continuous feedback process.

    But the reality is tools and processes are not what ultimately separates DevOps success from DevOps failure. Tools and processes help you to implement DevOps; but on their own, they don’t deliver the cultural priorities that allow DevOps organizations to thrive.

    This is an important point to digest. The market is teeming with tools pitched as critical enablers of DevOps, and there is no shortage of articles about why processes such as shift-left testing or de-siloing your team are important for DevOps.

    It would be a mistake, however, to assume that doing DevOps is as simple as implementing one of these tools and processes. If it were, we wouldn’t be spending so much time talking about DevOps in the first place, because it would be a trivial thing for anyone to achieve.

    DevOps Culture

    What matters above all in DevOps is culture. By culture, we mean the values and viewpoints that shape how your team approaches software delivery.

    If your team members don’t believe in constant collaboration and transparency as cultural values, no amount of continuous integration servers or real-time communication tools are going to enable you to achieve the type of team-wide collaboration necessary to support continuous delivery. Similarly, if your developers, software testers or admins don’t recognize the importance of doing continuous delivery in the first place, having the tools and processes in place to perform continuous delivery is not enough to ensure it actually happens.

    This is why instilling key cultural values is critical for DevOps. This isn’t an exhaustive, universally applicable list of essential DevOps cultural values, but most folks would include the following items in this category:

    • Collective accountability. Everyone on your team should assume responsibility for ensuring that software is delivered on time and meets expectations. Software delivery is everyone’s responsibility in DevOps.
    • A blameless environment in which the team as a whole, rather than individuals, owns the system.
    • In a DevOps culture, all team members should have constant visibility into what other members of the team are doing.
    • DevOps places a priority on minimizing manual effort. It promotes automation over allowing some team members to perform tasks manually in order to protect their turf or increase their individual value.
    • Collaboration and shared roles. In DevOps, no single engineer should exclusively own a particular task. Some people might bear primary responsibility for certain tasks, but at the end of the day, everyone should be permitted, qualified and willing to assist with any task.
    • Support from management for all of the above. Executives need to embrace the concept of collective ownership for IT processes, while also giving IT teams the flexibility to scale and change tools and processes as needed.

    Your Ecosystem and Your Culture

    How do you actually construct a DevOps culture founded on principles like those described above? Part of the answer lies in evaluating your current internal company culture, of course, and taking steps to change it.

    But another important part of the answer lies in your business’s ecosystem. After all, culture is not something that develops only on the basis of internal factors. Culture is influenced to a tremendous extent by what is going on around you.

    So, in order to build a healthy DevOps culture, think about what other companies you engage with are doing. In many cases, you can jump-start your DevOps cultural transformation by borrowing ideas from partners who have already been there.

    To be clear, I’m not suggesting you look only for partners who have won accolades as DevOps-first organizations, or startups that have had the benefit of coming of age when DevOps was already a big deal. Think also about established companies that have deep experience working with an array of different technologies, integrating those technologies and bringing them up-to-speed with modern software delivery practices.

    Those are the organizations that have sophisticated, organic cultures. They’re also the ones that know what it takes to update existing cultures to support DevOps. And they may be able to help you identify the specific tools and processes that will enable DevOps for your business.

    Building a Healthy DevOps Ecosystem

    As an example of what the process of constructing an effective DevOps culture might look like in practice, consider how you might approach this challenge if your ecosystem (like many today) includes a mix of modern, cloud-based infrastructure on the one hand, and mainframes on the other.

    This might seem like a difficult circle to square. Conventional wisdom tells us that mainframes may be difficult to integrate with modern DevOps processes.

    But that is not the case. IBM offers a range of solutions to help integrate mainframes into the rest of your ecosystem. For example, Z Open Development makes it possible to standardize your SCM and build processes for mainframes using modern, Git-based tooling. Likewise, Z Open Unit Test makes it possible to bring modern unit testing to mainframe applications. And you can even test and build mainframe apps on commodity x86 servers using Z Development and Test Environment.

    Of course, integrating mainframe infrastructure into the rest of your ecosystem using tooling like this also requires a culture and attitude adjustment. Developers and ITOps admins must move past the cliché that mainframes have no role to play in modern DevOps shops, or that they are too difficult to integrate into modern ecosystems. That’s not at all true and building a successful DevOps culture that embraces the mainframe means discarding this inaccurate viewpoint.

    Conclusion

    In short, succeeding at DevOps means adopting the right cultural principles to turn a DevOps toolset into an actual DevOps workflow. The good news is you don’t have to invent those principles from scratch. Look for an experienced ecosystem partner or partners who can help you in your DevOps cultural journey.

    — Chris Tozzi

  • Shift-Left Testing, Continuous Integration and the Mainframe

    Shift-Left Testing, Continuous Integration and the Mainframe

    “Mainframe” is one of the oldest terms in tech. “Shift-left” is much newer.

    You may not think, then, that mainframes and shift-left testing have much in common. But you’d be wrong. Shifting testing to the left can deliver tremendous benefits, even in the context of mainframe applications.

    Let us explain.

    What Is Shift-Left Testing?

    Shift-left testing refers to the practice of performing more tests earlier in the software development lifecycle.

    Traditionally, most testing occurred just before software was deployed into production environments. Testing code at this stage is useful for ensuring it will behave as expected in production, but it comes with drawbacks.

    The biggest drawback of traditional testing is problems are difficult to fix if they are not discovered until just before software is ready to be deployed. At that point, addressing a problem within the code requires determining where specifically the problem exists within the code, removing that code from the application and replacing it with updated code—all without breaking other parts of the application that depend on the original code.

    Shift-left testing helps to address this problem by encouraging software delivery teams to perform tests earlier—typically, starting right after individual units of code are written. Being able to test earlier and more often is especially important in software delivery pipelines based on continuous integration/continuous delivery (CI/CD), where the goal is to roll out application changes on a nearly continuous basis.

    Since bugs that aren’t detected until just before release can take a long time to fix, a lack of shift-left testing puts organizations at risk of not being able to achieve the main goal of CI/CD due to constant delays caused by software quality problems. In addition, shift-left testing reduces the amount of overall end-to-end testing you have to perform.

    You Still Test on the Right

    It’s important to note tests performed earlier in the pipeline don’t replace the testing done just before deployment. They complement them and reduce the chance of having problems go undetected until right before deployment. In this sense, the term shift-left can be a bit misleading; it’s not really about shifting all testing to the left of the delivery cycle, as much as it is starting tests earlier, while continuing to test on the right of the pipeline as well.

    Shift-Left Testing and Continuous Integration on the Mainframe

    Shifting testing to the left makes it easier to fix code problems within virtually any type of application delivery pipeline based on CI/CD. But it can deliver especially critical benefits for software delivery teams striving to bring mainframe applications up to speed with CI/CD.

    There are a few primary reasons why. One is mainframe applications are usually written using older programming languages that were not designed to help developers avoid mistakes. This isn’t to say mainframe languages are especially prone to errors; they’re not. But compared to a language such as Python, which is designed to enforce good coding habits, a language like COBOL doesn’t exactly require programmers to be highly disciplined when they’re typing out their code. Thus, it’s especially important to be able to catch bugs earlier within code written in a mainframe language.

    Another factor is mainframe applications are often part of legacy codebases. When you’re dealing with code and dependencies that are decades old in some cases, you’re at a greater risk of ending up with software quality problems, despite your best efforts. Here again, detecting those problems earlier rather than later means they can be fixed without interrupting the entire CI/CD process.

    Finally—and most important—is the fact that in some cases, there is a large disconnect in terms of skill set and familiarity with mainframe code between software quality engineers and mainframe programmers.

    Your typical QA engineer today didn’t grow up with z/OS and may have limited experience troubleshooting software problems. Given the QA team is typically responsible for running pre-deployment tests, this can pose a problem in the event that QA detects issues with a mainframe application that it has no idea how to troubleshoot, let alone fix. By shifting testing to the left, it’s easier to give developers faster feedback so that they can fix bugs more quickly.

    How to Shift Mainframe Application Testing to the Left

    If you thought mainframes had nothing to gain from the shift-left testing movement, you might also think there aren’t many tools out there to help you do shift-left testing for mainframes.

    Fortunately, that’s not true at all. For unit testing, IBM offers Z Unit, a unit-testing tool for z/OS programs. Z Unit is included in Z Open Unit Test and IBM Developer for z Systems. Using these tools, Z developers can automatically generate unit tests for batch and CICS programs as part of their daily work. These tests can be stored in any standard SCM and can be executed independent of their environment.

    You can even test mainframe apps on non-mainframe hardware using Z Development and Test Environment. The platform creates virtual Z environments on x86 systems so developers can write, build and test their mainframe applications on any standard commodity server or development box.

    Conclusion

    Whether your mainframe applications are decades old or have been written from scratch in just the past few years, there’s nothing stopping you from taking advantage of shift-left testing to help validate them. Doing so will make it easier to achieve CI/CD effectively for your mainframe application, which keeps your software delivery team and your end-users alike happier by reducing bugs and delays.

    Check out the Z Open Unit Test demo.

    — Chris Tozzi