|
Project leaders can juice developer efficiency using virtualization
January 24, 2009
URL:http://www.drdobbs.com/parallel/virtual-machines-real-productivity/212902020
Sean Campbell is principal of Cascade Insights, a competitive intelligence firm that works with software companies; contact him at [email protected]. Michael Jeronimo is a software architect for Intel, and he can be reached at [email protected].
Virtualization offers one answer to a major problem with software development: the consistency among developers' platforms. If the development environment is different from developer to developer, it's hard to isolate bugs in the software or identify what might be causing a problem. Is the problem in the code or the environment?
Virtualization tackles this by letting the leaders of development teams deploy identical environments to all developers working on a project. The benefits include ease of deployment, avoiding installation hassles, and managing geographically diverse development teams. Watch out for the downsides, such as the considerable time it can take to create and transfer virtual images. But the payoff can make it worthwhile.
For anyone leading a software development project, a common worry is whether all developers are working with -- and testing code against -- the same base platform. If developers aren't utilizing the same builds of tools and associated development applications, such as source-code control systems, during the development process, it's easy for discrepancies to creep in. It invites inconsistency when developers aren't using the exact same base operating system, with the same set of service packs and fixes.
Virtualization makes it easy to configure a development environment that has the specific service packs and hot fixes for a single, mandated base software development platform. Using virtual machines also makes it easy to mandate changes to development tools when new versions become available.
Whether you're using server-based virtualization or desktop virtualization tools, you can, in nearly every case, deliver a pre-built machine to developers faster than they could install the tool updates themselves. You want developers writing code, not fiddling with software installations. So, instead of distributing a new bug-tracking client, source-code control client, or bug-fixed version of a development environment to all developers as a raw software install, you can now configure once and deploy.
An IT leader can designate a core group to pre-configure and deploy the development environments, and over time they'll get faster and more efficient at installing such packages, rolling subsequent base configuration changes more rapidly.
The efficiency gains to a project can be significant, since deploying raw software can mean days or weeks before the entire development team has it installed properly and is up to speed on the update. This is especially true if development tools undergo a significant change, such as moving from one major development environment version to another. Visual Studio comes to mind. Don't assume developers will make short work of installations; it's common to have a developer exceptional at writing C# or Java code beset with trouble installing a software package.
Having a common, virtual development environment also gets around installation conflicts caused by personal software and plug-ins on machines. Problems also can spring from valid experimentation, as developers download hot fixes, service packs, software development kits, and utilities, or they configure a base operating system differently than the corporate defaults, all in an attempt to trace down a bug. All these changes can contribute to delays in loading mission-critical software needed to keep the development team productive and moving forward to hit a target release date.
In addition to giving the development team a standard development environment, it's also valuable to provide a locked-down VM preloaded with the necessary software the company uses, from settings to access services to messaging. So regardless of what happens to their machines' software state, developers can connect through e-mail, instant messaging, and other means. But lock down this productivity image even more thoroughly than a development image, so it doesn't get modified unnecessarily. Some users won't like it, but by limiting the lockdown to a virtual machine, and not the host machine or all VMs, it's less likely the users will try to circumvent security enhancements.
Even with a virtualization strategy, however, it's still worth considering giving developers a dedicated machine that's used only for remote access scenarios to the corporate network.
In many ways, the FedEx or UPS delivery person can be a significant asset when using VMs as part of a development effort.
When developing software applications with diverse teams, remote teams can get out of sync with the base development platform. Of course, this can be resolved through conventional updates, but, using a standard virtual image, it's much more efficient to "install once and ship anywhere."
By having a centralized team configure and ship virtual units, project leaders can be more confident that widely diverse teams can quickly be up and running with the exact same development platform without worries about individual configuration problems. It's particularly important for dispersed development teams to get quickly in sync on a similar set of images if, for example, a remote team is developing the middle tier for an application and a local team is developing the client and server tiers.
This capability also brings peace of mind knowing that a development team can easily transition to more productive tools or versions, regardless of the development team's location and without significant lost productivity.
There's a downside, naturally. One limitation of VM technology is that it currently takes a good deal of time to compress, transfer over the network, or burn images to DVD. Also, there's additional time and expense to prepare and ship these DVDs.
An alternative distribution technique uses a server-based solution that developers log on to remotely. Using a product such as Xen 3.0, GSX, ESX, or Virtual Server, you can quickly set up a remote environment that developers can log on to with a Web browser.
Virtualization can save time for developers fine-tuning applications to various audiences around the world, something increasingly important to companies. Adapting applications for new markets and languages can result in a large amount of testing and development work. Changing an English-language character set to display Asian characters may throw off the fit in screen displays, labels, and messages for the user. The program may need bi-directional awareness to handle languages that read from right to left, and shortcut key combinations may not make sense for another language. The list goes on.
Being able to easily create a bank of VMs that can be copied locally or accessed through a server-based virtualization product makes it much easier for a company to add support for languages other than the language for which the application was originally developed. That's because it's possible to have each machine pre-configured for a particular locale at a fraction of the cost it would take if physical machines were used to support a large number of different locales.
The cost to add languages as time passes also falls, as teams get skilled at building out a new library of VMs configured for various locales and geographies and distributing them to the development team.
Localization is just one competency that's likely to become more important with the continued rise of emerging markets. Virtualization technologies can give leaders of an application localization effort more flexibility in the deployment and storage of a repository of VMs already configured for various locales and geographies. Those advantages will help application development leaders tackle any number of complications created by the globalization of software development, and of business processes generally.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.