Continuous integration works for distributed development -- why not do it on the mainframe, too?
Wes Simonds 120000EFD6 firstname.lastname@example.org | | Emneord:  assurance wes integration radcliffe quality product-innovation development workbench continuous system rational distributed greenhat software z ibm test simonds rosalind mainframe testing
0 kommentarer | 8.943 besøg
The problem with the phrase ‘business agility,’ if you ask me, is that it has now officially been used too many times, in too many different ways, to mean anything very definite.
I therefore propose getting rid of this particular adjective/noun combo and replacing it with a verb: respond. Four examples follow:
That last one, in fact, seems particularly important because in many cases, it's the one that makes the first three possible.
Distributed to mainframe
Thing is, many organizations that use mainframes for production services often haven't really figured out the best way to use them to develop new software. Common problems in this scenario include:
Fortunately, it seems that IBM Rational not only has been listening to its customer base, but has also -- wait for it -- responded by rolling out solutions that deliver a better outcome. This happens through an idea called ‘continuous integration.’
Now, if you develop for distributed systems, you're probably already familiar with this idea. Basically, it's this: You don't get all your developers to write code over a long period of time and then test it -- collectively -- at the end of that period. Instead, developers continuously test new code as it's written, and when it passes quality-control tests, they integrate that new code right away.
As a result, the total amount of recoding declines, projects are completed faster, applications work better and once deployed, they create more value for both you and your customers/users. All of which means your organization is now a whole lot more responsive… and a whole lot closer to modernizing your enterprise.
Speed System z development by empowering individual developers
The point of IBM's new approach -- according to Rosalind Radcliffe, Distinguished Engineer and Chief Architect for Jazz for System z and Power -- is to take this excellent idea from distributed development and stir it into mainframe development.
‘With continuous integration for System z,’ said Radcliffe, ‘we're giving the z/OS development community the same capabilities that have long been available for the distributed world. That means, among other things, giving developers their own test environments, and the ability to run automated tests without affecting production capacity.’
There are actually quite a few ideas implied there, involving four different IBM solutions. Let's walk through them in a bit more detail.
If you want new code to be continually tested and integrated, obviously you have to give developers some way to do that. That means giving them local environments in which they can assess code quality, isolate problems and fix those problems -- all the things Java developers working on distributed platforms are used to.
IBM's response to that concept: IBM Rational Development and Test Environment for System z . You can think of this solution as almost creating a System z in miniature -- running on the developer's desktop or laptop -- which is good enough to test new app code. Because that environment isn't running on the System z proper, it's also not consuming System z resources, meaning that the System z is free to concentrate on up-and-running apps and services. (This is what Radcliffe means by ‘without affecting production capacity.’)
Given that System z environment-on-the-desktop, how do developers create new local builds to test the new code? Answer: IBM Rational Team Concert -- a lean, collaborative solution well suited to this task.
Okay, so you now have local testing environments and local app builds running inside them. How do you optimize testing of those builds?
You give your developers the power to automate as much of that testing as possible. If there are two test cases to run, sure, a manual approach may suffice. What if there are 500? A thousand? Tackling a number like that manually is a real drag -- not just to the developer, but to the project as a whole, and ultimately, to the organization.
This is where IBM Rational Quality Manager and IBM Rational Test Workbench -- the other two pieces of the continuous integration puzzle -- come in. Using them you can handle the code testing per se, automating much of it for a faster and more complete process. You can also test the web service interface -- the front end through which customers/users will actually experience the app, which may or may not need to change to match the new code.
Faster deployment, lower risk, easier project management, bigger smiles
The result? All the theory of continuous integration, and the intended benefits it's long generated in the distributed world, now apply to System z development, too. In particular, new application releases can be tested far more quickly, get rolled into production faster and start creating all the value they're supposed to create.
This is all likely to come as very welcome news to System z developers who may have gotten used to the idea that testing always means slow.
‘In the past, application changes took far too long to deploy to production due to these long testing cycle times,’ said Radcliffe. ‘Months were needed to change an application even in a relatively simple way. Not any more. With our new approach, where we have automated test buckets, those months can fall to weeks -- or days.’
There's also an improvement in risk -- a major concern in the case of mainframe-hosted applications that perform mission-critical tasks, on which the success or failure of the entire enterprise may depend.
Think, for instance, of banks that run applications that support online banking. I can't speak for anyone else, but if my online banking experience frequently seemed unreliable or inconsistent, I would most likely pack up my business and split, looking for another bank that knew how to get this stuff right. And banks, which are well aware of this line of thought, are perhaps a bit skittish about introducing application changes if they think those changes could lead to the packing/splitting outcome just described.
‘Risk definitely declines with continuous integration,’ said Radcliffe. ‘That's because developers can begin to build up their regression buckets with automated tests for any areas they are currently developing in -- especially for areas that are expected to cause difficulty when changes are made. Then, by tracking and storing these tests, they can establish that actually making the changes will be significantly less risky -- a new build will actually do what it's supposed to do, the way it's supposed to do it.’
Finally, project management is also enhanced. What had been a super-complex, difficult process of orchestrating testing and quality assurance across large teams of developers is now rendered much simpler and more consistent in a couple of different respects.
‘First -- the new continuous integration solution means the testing process can be standardized across the entire team,’ said Radcliffe. ‘Because the process is standardized, it's much better understood, runs much more smoothly and yields better, more predictable results. Second -- the products used to carry out the process are also now standardized. Since everyone has the same tools, and is using them in the same way, you get simplified management and you have an easier time scaling projects. If a new developer is needed in a given group, it's very clear what tools she'll need -- and how she'll be using them.’
Learn more about Enterprise Modernization solutions
Join Rosalind Radcliffe for an InfoWorld Webcast -- Smarter Development and Testing for IBM System z
Check out additional resources on continuous integration
Stay current on software & systems innovation with The Invisible Thread
Find out how to increase your services without breaking the bank
About the author
Guest blogger Wes Simonds worked in IT for seven years before becoming a technology writer on topics including virtualization, cloud computing and service management. He lives in sunny Austin, Texas and believes Mexican food should always be served with queso.