One Little, Two Little, Three Little Versions
原文请见：http://blogs.msdn.com/micahel/archive/2006/06/14/OneLittleTwoLittleThreeLittleVersions.aspx
A reader asks:
Can you shed some light on how to plan out versioning in test? I am on a project where historically no versioning has been done. The functional tests are just re-written and modified to suit the updated feature. I would like to introduce versioning but am not sure where to start!
Version control is very important for every aspect of the software development process. It doesn't matter whether your team is comprised of one person or one thousand people, version control will save your tail one day! I find version control indispensable, even for my personal projects. And all those digital photos I snap? Safe in version control!
With respect to testing, there are several areas to consider when introducing version control:
Application under test. If your application isn't versioned there's not much point in versioning anything else! Versioning the source code for your application is a good starting point, but you may want to go further. Archives of your nightly builds often come in handy, such as when you're trying to determine in which build a bug first appeared. At the very least archive any build you release to customers! Consider archiving not just the bits for each version but an entire virtual PC with your app and all other dependencies installed. These are useful not just for reproducing customer issues but also for tasks like upgrade testing.
Sample files, help files, and other content. Yes, even specifications and design documents. My team doesn't version specs and design docs (although I wish we did!) but all other content is in version control right alongside the product code. This is especially important for us, as each new build of Windows Presentation Foundation may force us to update all of our sample files and projects due to breaking changes in XAML. Even when you're building on a stable platform, however, versioning your content lets you roll back to previous versions, easily handle multiple people modifying the same document, and all the other nicenesses version control brings to your product code.
Test cases and test libraries. Test code is just code. The only difference between the code testers write and the code developers write is that the testers' code (usually) isn't shipped to customers. Testers should follow all the processes and procedures as their developers do: planning what they write before they write it, design and code reviews, unit tests, static analysis, daily builds, and version control. Beyond that, however, test cases are necessarily tightly tied to the application they test. If you version your test code, it's a snap to run all the tests for some previous release while ignoring any test that was written since. If you don't version your test code, then this sort of thing is likely to become a nightmare!
Infrastructure and tools. Versioning your product code, test code, and content is great, but if you don't also version the tools and infrastructure you need to turn all those zeros and ones into a shippable product you'll still be out of luck when you need to prop a new build of last year's release. My team, and many others at Microsoft, can take a raw machine, sync it from version control, then use it to build their app. They check in everything: the compiler, the static source code analyzer, the test harness, even the build system!
It doesn't really matter where you start, just so you start somewhere and eventually get everything versioned. Getting your product and test code versioned is the most critical I think - if that gets lost you're pretty much out of luck. But look at your specific situation: which parts of your process get clobbered the most? Those are the parts you should version first. 版本控制之道.
有些细节翻译有困难.
页:
[1]
