The Online Business team at HP enables customers to try and buy SaaS-based versions of the company's software products. It's a massive undertaking, requiring a DevOps approach and as much agility as the team can muster. For the past year, senior engineering manager Vadim Iofis has been leading the technical effort. He's well suited to the task, having spent several years in web app development at Yahoo, where he developed small business services, including Yahoo's GeoCities.
It was at Yahoo that Iofis learned much of what he knows today about agile development, catering to millions of users with applications that supported many types of business customers. Prior to that, Iofis spent five years at VMware, where he worked on virtualization and infrastructure services.
TechBeacon chief editor Mike Perrow recently sat down with Iofis to talk about agile development, DevOps, and other aspects of his team's software delivery process.
TechBeacon: What changes have you seen in agile development methods since you began your career in the early 2000s?
Vadim Iofis: At Yahoo, two to three application deployments per month was considered quite agile. We spent our efforts on developing tools and processes, but not on delivering frequent updates to customers. We probably could have doubled this frequency, but the business team didn't want to deliver rapid changes; they wanted predictability.
Today, our overarching goal is delivering frequent updates to our end users. In fact, our motto is "to continue developing the capability and confidence to deliver to production on a frequent basis." This is very much in line with our agile process: frequent delivery to end users, constantly improving tools and technology.
TB: Are you taking a DevOps approach to the development and delivery cycle?
VI: Absolutely. Our process is what DevOps is all about. We are aligning the development and the operations side to the point where the lines between the two are blurred. There is a single end-to-end process for everyone that runs from development through testing, deployment, and running the application in the production environment. This is different from the classical model, where you have a development or R&D team serving the production team as their internal customer. You hand off to them, and their first experience with the application is in production. Our goal is to avoid that type of separation. Not just because that's an outdated model, but because it really does create friction within the development and delivery cycle.
TB: Can you give an example?
VI: We have invested a tremendous amount of time developing deployment scripts. These are used to deploy an application into all sorts of environments, and this was a cooperative effort between the development and operations teams. There's nothing more DevOps than this. The effort really gets to the heart of our motto: having the capability and the confidence to deliver. The deployment scripts particularly address the confidence part. We not only worked to create these scripts, but we also test them continuously. Each developer tests every single new feature using these deployment scripts, deploying that feature either into their own environment or into a QA environment. The bottom line is that the development of a feature is equal in importance to the development and testing of the deployment script supporting that feature.
TB: Are you using deployment scripts in lieu of traditional testing?
VI: It's a supplement to testing, not a replacement. They're designed to push the code changes within the application stack, as well as run against any database update. The key goal is to use the exact same set of deployment scripts across all our environments, including the personal environments of each developer. When developers know that a change works, they have the confidence to know their feature will work in production. Their fellow developers do testing on that same code base, as well as the QA team. It means that we test the deployment continuously, sometimes up to 10-15 times per day. When you do over 100 deploys per release, you gain the confidence that everything will work in a predictable way.
TB: Are you using aspects of test-first design in your development process?
VI: Yes, we develop unit and integration tests with our internal partner teams. But the most important aspect is making sure that all of our deployment environments are well tested.
TB: Why did you choose scrum over XP or spiral methods for agile development?
VI: Scrum gives us several things in one nice package. First, it helps us meet our goals for having defined, frequent deliveries to end users. We have a release life cycle that is directly aligned to our sprints, which means we have a two-week mini project twice a month.
Second, we find that scrum protects our developers from too much instability around requirements. We have product managers who must finalize requirements by the first day of sprint planning—day one of each sprint—which means our teams can lock down the scope of the next iteration's delivery.
Third, the fact that it's only two weeks gives the product managers enough flexibility to change the business direction, adjust requirements, and reprioritize them over a short space of time. We are currently in our 37th sprint, and the process has proved successful for us.
TB: Describe the transition to deployment at the end of each sprint.
VI: Our QA team creates a final testing sign-off that asserts everything has been well tested and is bug-free. This acts as a trigger for the production team to take that final build and deploy to the production environment. This makes the job easier, in that the operations/production team is familiar with the new features upon deployment. My team is focused on delivering our builds to production, having benefited from testing the deployment process extremely well, along with the features themselves. So essentially it's a very smooth, fully automated process that takes no more than 10 to 20 minutes to deploy everything, depending on the size of the build.
TB: How has your user base dealt with the frequent updates from your DevOps cycle?
VI: They appreciate having their needs met on a regular basis. One of the key reasons for frequent deployments is our need to receive rapid input from our users. That comes through different forms. One is a contact form on the site where users can submit their issues. We also rely on monitoring tools that log errors. We take all that feedback in and reiterate, making agile adjustments frequently, based on what is relevant to our user base.
TB: Given your background at VMware, why did you choose Docker as the tool for virtualization in your development environment? How does the container approach improve over traditional VM capabilities?
VI: We see Docker as a groundbreaking technology that actually enables the DevOps approach to development. For us, it lets us recreate all of our environments so they more closely simulate production, which typically has multiple servers running. But that isn't practical in the development environment itself. It's cost prohibitive, and individual developers can't run multiple servers on their laptops. But with Docker, we can turn each server into a segregated container with a very small footprint with just enough memory—just enough share of the CPU—that we can set up all these containers on the same laptop in the same way they'd be set up in a production environment.
From an infrastructure perspective, the container becomes a unit of infrastructure. The other benefit is that we package our entire application into these containers so that the implementation is greatly simplified. Our developers can work on their applications in the context of these containers and deliver code into the repositories in that same form, so that the deployment mechanism only has to deploy the new versions of these containers into whatever environment.
The container capability allows our developers to work on the application and the infrastructure at the same time. It erases the boundary between development and operations, and improves maintainability and efficiency for us.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
