It's here - my full article on Making Your Automated Tests Faster, on the Enterprise DevOps blog! Thank you again to the dozens of people who contributed their ideas at DevOps Days Rome.
This reminds me of my earlier post on "death by build", and how a build that takes too long, due in part to slow test automation, can really hamper a project: Is Shift-Left Agile? And Death By Build
Wednesday, November 14, 2012
Tuesday, November 6, 2012
Interview about DevOps and SmartCloud Continuous Delivery
Here's an interview I recently gave to a fellow colleague of mine, Tiarnán Ó Corráin. This seems like a good time to reiterate that these views are my own, and not the official views of IBM:
What is DevOps?
You can think of it as an extension of the principles and practices of Agile. Where the Agile methodology breaks down the barriers between development and business goals, DevOps is breaking down the barriers between development and operations. It's not all about tools; it's about people and processes as well. Both Agile and DevOps have a goal of delivering reliable software to the business more quickly, and ultimately, making more money!
How does DevOps do that?
Well, traditionally there has been a problem between going from a development system to a production system: installing new machines, installing the software, scripting and so forth. Getting from a working development system to a working production system involved all of these manual steps, and introduced many points of failure.
In addition, because setting up test machines was so time-consuming and error-prone, developers would often assemble their test machines in a quick and dirty way, on a single server, with the cheapest, simplest components. Production systems, on the other hand, would have multiple servers, configured for clustering and fail-over, with firewalls between some components. This meant that the developers weren't testing the software in an environment similar to the one where it would run in production. And because of that, some bugs were never found until the software was deployed into production.
One of the primary tenets of DevOps is that you should automate every step in creating production systems. Everything from preparing the machine, to installing the latest software, to starting the services, and testing them, should be fully automated and repeatable. And when creating production systems is automated, you can also use production-like systems for development and test work.
How does virtualization help that?
When we're working in a cloud environment, deploying a virtual machine is something that can be scripted and automated. We use infrastructure code to automate deploying the machine, installing the software, and (re)starting the services, and then we check that code into our source code repository and version it just like the application code. So effectively the process of deploying a new system becomes part of the development process.
Presumably that makes testing easier?
Very much so. Our virtualization technology means we can deploy production like environments as part of the development process. It's the way the development process has been trending recently. We already have continuous integration: RTC (Rational Team Concert) triggers automatic builds when changes are submitted, and we run unit tests against those builds.
Now, take that to the next level with continuous delivery: after changes trigger builds, those builds trigger deployments, and when the deployments are complete, the builds trigger automated tests. What it means is that as part of the development process, we have production like servers running the latest code. This allows us to run automated tests including performance verification against a production like environment as part of the development process.
Taking Agile to the next level?
Yes. It accelerates development, because it takes away some of the uncertainty about deployment: if I can capture every part of the deployment process in my development and testing process, I have more confidence about what I'm going to deploy.
Deploying test systems automatically also saves developers and testers a lot of time! On my own development team, it's normal for us to deploy dozens of new servers every day, and delete the old ones just as often.
Can you tell me a bit about your own role?
I'm on the advanced technology team that works on DevOps. We are driving an internal transformation within IBM, to encourage our own development teams to adopt DevOps principles and practices. In addition, we are creating tools to help IBM's enterprise customers adopt DevOps themselves. The first tool we developed to sell is SmartCloud Continuous Delivery v2.0, and it's shipping to customers this week. SmartCloud Continuous Delivery is currently targeted at customers who want to improve their dev/test cycle. We believe this is the easiest place for our enterprise customers to start taking advantage of these new technologies. We have other tools to help with production deployments, like SmartCloud Control Desk.
How is it going down in the market?
These ideas are gaining real traction, both within and outside of IBM. Internally, we already have several adopters of continuous delivery for dev/test. For instance, Rational Collaborative Lifecycle Management is using our code, and other teams like SmartCloud Provisioning 2.1 have custom continuous delivery solutions that are very similar to ours. And of course, we're using it ourselves -- SmartCloud Continuous Delivery is self-hosting.
What would you say to any teams that are interested in this approach?
If anyone would like to evaluate the SmartCloud Continuous Delivery product, please check out our website. We have free trials available.
Even if you're not a good candidate for SmartCloud Continuous Delivery, your team may be able to use several of the DevOps principles and practices. Check out our Enterprise DevOps blog for ideas, and feel free to contact me about that as well. IBM even offers DevOps consulting workshops.
What is DevOps?
You can think of it as an extension of the principles and practices of Agile. Where the Agile methodology breaks down the barriers between development and business goals, DevOps is breaking down the barriers between development and operations. It's not all about tools; it's about people and processes as well. Both Agile and DevOps have a goal of delivering reliable software to the business more quickly, and ultimately, making more money!
How does DevOps do that?
Well, traditionally there has been a problem between going from a development system to a production system: installing new machines, installing the software, scripting and so forth. Getting from a working development system to a working production system involved all of these manual steps, and introduced many points of failure.
In addition, because setting up test machines was so time-consuming and error-prone, developers would often assemble their test machines in a quick and dirty way, on a single server, with the cheapest, simplest components. Production systems, on the other hand, would have multiple servers, configured for clustering and fail-over, with firewalls between some components. This meant that the developers weren't testing the software in an environment similar to the one where it would run in production. And because of that, some bugs were never found until the software was deployed into production.
One of the primary tenets of DevOps is that you should automate every step in creating production systems. Everything from preparing the machine, to installing the latest software, to starting the services, and testing them, should be fully automated and repeatable. And when creating production systems is automated, you can also use production-like systems for development and test work.
How does virtualization help that?
When we're working in a cloud environment, deploying a virtual machine is something that can be scripted and automated. We use infrastructure code to automate deploying the machine, installing the software, and (re)starting the services, and then we check that code into our source code repository and version it just like the application code. So effectively the process of deploying a new system becomes part of the development process.
Presumably that makes testing easier?
Very much so. Our virtualization technology means we can deploy production like environments as part of the development process. It's the way the development process has been trending recently. We already have continuous integration: RTC (Rational Team Concert) triggers automatic builds when changes are submitted, and we run unit tests against those builds.
Now, take that to the next level with continuous delivery: after changes trigger builds, those builds trigger deployments, and when the deployments are complete, the builds trigger automated tests. What it means is that as part of the development process, we have production like servers running the latest code. This allows us to run automated tests including performance verification against a production like environment as part of the development process.
Taking Agile to the next level?
Yes. It accelerates development, because it takes away some of the uncertainty about deployment: if I can capture every part of the deployment process in my development and testing process, I have more confidence about what I'm going to deploy.
Deploying test systems automatically also saves developers and testers a lot of time! On my own development team, it's normal for us to deploy dozens of new servers every day, and delete the old ones just as often.
Can you tell me a bit about your own role?
I'm on the advanced technology team that works on DevOps. We are driving an internal transformation within IBM, to encourage our own development teams to adopt DevOps principles and practices. In addition, we are creating tools to help IBM's enterprise customers adopt DevOps themselves. The first tool we developed to sell is SmartCloud Continuous Delivery v2.0, and it's shipping to customers this week. SmartCloud Continuous Delivery is currently targeted at customers who want to improve their dev/test cycle. We believe this is the easiest place for our enterprise customers to start taking advantage of these new technologies. We have other tools to help with production deployments, like SmartCloud Control Desk.
How is it going down in the market?
These ideas are gaining real traction, both within and outside of IBM. Internally, we already have several adopters of continuous delivery for dev/test. For instance, Rational Collaborative Lifecycle Management is using our code, and other teams like SmartCloud Provisioning 2.1 have custom continuous delivery solutions that are very similar to ours. And of course, we're using it ourselves -- SmartCloud Continuous Delivery is self-hosting.
What would you say to any teams that are interested in this approach?
If anyone would like to evaluate the SmartCloud Continuous Delivery product, please check out our website. We have free trials available.
Even if you're not a good candidate for SmartCloud Continuous Delivery, your team may be able to use several of the DevOps principles and practices. Check out our Enterprise DevOps blog for ideas, and feel free to contact me about that as well. IBM even offers DevOps consulting workshops.
Subscribe to:
Posts (Atom)