Toward the end of the last Batman movie, when Robin is giving Batman a hard time, George Clooney gets fed up and says, "This is Why Superman Works Alone." While I'm often tempted to think along the same lines, the reality of our business is that we work in teams. This leads to the topic of this month's diatribe: team development.
Large-scale software development is a complex process. The majority of it takes place in a corporate environment that requires rigor and process. The most familiar of these processes is usually the task of obtaining the blessing of the DBA for your database schema, or for changes you need to make to it. Due to the nature of the corporate database, the DBA process is almost an island unto itself. I'll rant about that some other time because right now I'm interested in team development and its partner - configuration management.
It's my belief that the companies creating source code control tools today are missing the big picture. You'll notice that I said "configuration management" in the previous paragraph and "source code control" in this one. In my mind there's a big difference between them; while source code control is vital to any project and is indeed part of configuration management, it is by no means the whole picture. Mention configuration management to a typical project team and you'll get an answer like, "Oh yeah, we use" (which can be filled in with any of the current generation of source code control tools).
Unfortunately, this misses the point of configuration management because it addresses only a small portion of the entire task - the part relating to developers. The typical configuration-management dilemma encompasses tasks such as unit, system and integration testing; software builds and deployment; and, in the era of multitiered Web applications, distribution and registration issues.
We need to establish a set of standards for these practices so they can be automated and controlled. It's a complex issue, but that's the whole point of paying a good deal of money to a vendor to come up with a solution. Every time we begin a new project we have to tackle the same issues over and over. This is an opportunity for an up-and-coming ISV to create a new product line and dominate the industry.
What we need is a meta tool - one that's language-independent but can interact with any of the major development environments. It could start with source code control. Most organizations I've worked with don't allow developers to directly create executables - as part of the QA process the testing team usually creates them. And they typically suffer from a lack of expertise in doing just that because their main focus is on testing, not building. The first step would be automating the build process, then representing it in a graphical manner that makes it easy to define and automate. Please don't tell me about nmake or other command line utilities - it's been my experience that people who are typically charged with the build process aren't the kind of heads-down developers who can make that kind of tool workable. A simple graphic tool is needed.
The next step is to establish standards for code deployment and registration. Most multitiered environments use some sort of application server, be it MTS, Jaguar CTS, Tuxedo/M3 or one of the CORBA Orbs. As code is produced, and as it changes, redeployment and registration of components within these servers become an issue. The establishment of a common mechanism for supporting this process would enable our new meta tool to automate this process. I spent a great deal of time on a recent project ensuring that registration and CLSIDs were current. It was largely a mechanical process that didn't need to eat up a lot of time if a tool had been available.
Hand in hand with the application server deployment is the replication of environments. In most cases the code above goes to more than one application server (development, testing, various production systems, etc.). Perhaps a publish-and subscribe paradigm, with the meta tool being the publisher, would be appropriate.
Finally, deployment and synchronization of the client code is still an issue. Fortunately, we've had more time to think about this one, thanks to client/server, and there are tools available to help. Unfortunately, none that I'm aware of tie into a more global model, so even with these tools you have some type of routine setup and maintenance.
I'm not holding my breath waiting for this meta tool. Having wrestled with these issues for years, I know how difficult it is to establish a set of vendor-neutral standards and get the industry to adhere to them. But I do know we need them. In the meantime, I'm going to take my Kryptonite laptop somewhere quiet and do some real coding. Up, up a
<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
扫一扫
411
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
