Planning Your ClearCase Deployment
- Planning to Plan
- Now You Know . . . and Knowing Is Half the Battle
This chapter is from the book
This chapter is from the book
This chapter is from the book
How often do you visit fortune-tellers? Not many of us make a habit of visiting the local palm reader before making major software decisions. But how much different is a visit to the friendly neighborhood soothsayer compared to many of the "shoot from the hip" decisions we make? If you're about to implement a very large ClearCase solution, you might find yourself cutting corners in the name of time. How different is corner-cutting from fortune-telling? Let's hear the rationalizations: You manage a team of smart, competent people who should know exactly what they're doing, right? The software comes with full documentation, and the default install process is fairly simple, right? The new software should plug right into your team's existing infrastructure and development processes, right?
Since we're leaving so much of your future to fate, let's look at your options from a fortune-teller's perspective: Down one path we see pain, misfortune, and possibly failure. This might equate to poorly defined requirements, improperly defined handoffs and procedures, and a nonscalable architecture. Down another path, we see hard work but smart management of your intellectual property assets and, ultimately, success.
Designing and building a software configuration management solution is much like following the counsel of a palm or tarot card reader if you don't plan for it: without proper planning, you're letting fate decide your success. Remember the old adage, "If you fail to plan, you plan to fail."
Gosh, that always sounded so hokey when our parents or teachers threw it into a lecture or reprimand—and yet we've seen firsthand how poor planning has affected far too many teams and projects, usually with the justification of shaving a few man-hours from the schedule.
Here's another way to think about it: You're getting ready to take a long trip overseas. Do you just grab a backpack, throw in some odds and ends, and head for the airport? For most of us, of course not. You think about what you'll need, maybe you jot down a list of items to bring along. You do some planning, think about how many days you'll be gone, which clients you'll see and in what social settings, the weather at your destination, and the extracurricular activities you might partake in. Yes, you could throw into your bag an extra pair of shoes, some socks, and a few pairs of underwear and probably make it for a few days. But is skipping some planning steps up front really worth all of the trouble? Four days down the road, you don't want to be stuck in a meeting with clients in Singapore wearing the same outfit you wore on the plane, without fresh socks and underwear . . . metaphorically speaking, of course.
Planning to Plan
It's quite simple: you need to plan. Here's a start: think about all of the actors. Understand their relationships. Build your use cases. Apply them to your business rules for validation. And then build your plan. It all begins with a few targeted questions. But do you even know which questions to ask?
The questions posed here are nothing but a starting point to building a system and tool set that meet your organization's long-term development needs. We all suffer from "writer's block" from time to time, so think of this list as a tool to help grease the wheels in your brain. Here's where we recommend you start.
How Big Do You Think the Project Will Be?
This is an interesting question and oftentimes difficult to answer. How do you determine the size of the project? Do you use lines of code (LOC), number of classes, function points, or what? In most cases, the LOC is a good start for determining the size of the project. You can use several different methods to project the LOC for a project. Check out A Discipline for Software Engineering, by Watts Humphrey (Addison-Wesley, 1995), for some ideas.
How Many People Will Be Involved in the Product Development?
The size of the project is determined not only by the amount of code you will produce, but also by the number of people on your development team. Many times you can "guesstimate" the number of people that you will need on the team. When doing this, don't forget about the supporting roles of software development: QA, project managers, technical writers, and even managers. These people need to access the code and can therefore benefit from using ClearCase just as much as—if not more than—the software engineers.
Some might say, "We don't need to worry about the size of our VOBs because the new ClearCase architecture allows us to have really large VOBs." Just because you can have huge versioned object bases (VOBs) does not mean you should have them. Let's not forget that segmentation and the use of multiple VOBs have their benefits.
At How Many Locations Will the Product Be Developed, Tested, and Deployed?
If your first inclination is to answer, "Well, we're only here at the one location," or that your team can just telnet into the central office to do their work, then your project is either really small or you are not thinking big enough. With the expansion of broadband communications throughout the world, more companies are looking for cheaper ways to get teams to work together. It is expensive to move your whole team to the Silicon Valley when you can just as easily put a VOB server in each employee group's geographical location. Or maybe the product is being tested or developed overseas. The number of locations and the work that each location is performing will play an important role in your VOB architecture, triggers, and integration with third-party tools.
Is the Product External or Internal?
If the product is external, what delivery mechanism are you going to use? Are you burning a CD, are you providing an Internet download, or are you supplying a service? Can you use a VOB to control your releases? How often do you need to release the product to the customer? Is the product mission-critical for your customers?
When a product is internal, you typically have to deal with internal integration problems in addition to the normal external customer problems. Are other teams going to use your project to develop their product? Are they using ClearCase? (In a perfect world, everyone is using ClearCase.) How often can they get releases from your team? And what kind of coordination do you need to provide?
What Third-Party Tools Will You Be Using?
How many third-party tools do you plan to use? Make a list of all of the third-party tools that your development team (that is, your expanded team, as mentioned previously) is using. Don't forget about project management, testing, and technical writers. It makes sense to have some kind of VOB strategy for these tools. This includes things such as OS patches, compilers, Quantify, Purify, FrameMaker, MSWord, and so forth. There is nothing worse than having to spend weeks patching a mission-critical product that is over five years old, and you don't have access to all the tools you need to build, test, and document the thing.
What Is the Development Cycle of the Product?
Are you using a traditional waterfall method to develop your product? Is your cycle time Internet-fast (three months) or telecom-slow (seven years)? This can play an important part in the way you lay out your VOBs. You want to make sure your VOBs and ClearCase are not getting in your way, and actually help you get your job done faster. If you have a plan, you can use triggers to help enforce policy and automate things that are typically done by hand.
If you cannot answer this question about development cycle, let us point you to the Rational Unified Process. It is a good place to start for those in need of some direction.
How Do Your Current Development Methodologies Fit into Your Tool Plans?
We have seen far too many groups change their process to fit their tool set. This can be a dangerous exercise in bureaucracy. You might find processes that nobody can remember instituting, or that have no defined purpose. We have even seen processes created in an effort to circumvent the original process that no one could remember creating or instituting. Most of the time, we view these as shortcomings of the tools your team uses. It's important to find the right tools to fit your methodologies. Most today are very flexible and customizable and can handle whatever processes you might come up with.
Are Any Key Roles Missing from Your Team?
Make sure you have included everyone in the development team you need. Think through several scenarios. Were you asked recently for information about the project from someone who you don't have on your list as a key player in the development of the product? What was his or her role, and should your team be expanded to include this individual? If you are working with more than one location, who is the person responsible for coordinating meetings with all locations? Who is your multi-site administrator? Does your customer need access to ClearCase release VOBs? Make sure you have everyone written down.
What Are the Security Issues?
Don't fall into the trap of believing that just because you are behind a firewall your project is automatically secure. There are several issues that could pop up which you might not have considered. For example, you may have customers that want you to test your product against their proprietary systems, or some other protected intellectual property. You may need to restrict access to parts of your data while keeping other parts open between the customer and your development team. Another consideration: how can you protect your code from theft by a former employee? These are questions you need to ask.
What Types of Artifacts Are You Creating?
If your answer is, "I produce code—nothing else," then you are actually in the very small minority. Most products include documentation, binaries, project plans, images, and various marketing collateral. Map out all of the types of artifacts you need to version. A good rule of thumb is this: anything that is shipped or consumed by the end customer should be put in the source control system.
Do You Have the Hardware You Need?
It is really hard to deploy a development environment and ClearCase without hardware. Although it can be done, there is nothing worse than putting your VOB server on someone's desktop machine. You never know when you will have a janitor turning machines off in the middle of the night to save energy or, more commonly, have the air conditioning in your office turned off on the weekends to save money. That one is always fun. Make sure you have the hardware that you'll need up front. It is much easier to do it right the first time than to try and fix things later.
Do You Have the Infrastructure Ready to Support Your Plans?
Another item that people often forget is the infrastructure to support their development plans. Air conditioning, power, floor space, and networking are important to ensure you have a successful development environment. For instance, if you have to boot your machines in a specific order so you don't throw circuit breakers, you definitely need to get more power. If the $12.99 "blue light special" fan from Kmart keeps your computer from overheating, you need more A/C. Another thing to consider: if you are developing in multiple locations, you will need to make sure that you have connectivity to all locations (it's the little things—like connectivity—that always come back to haunt you). The hardest part, of course, is convincing someone who has the money to make the investment. If you do the work up front and have your project properly planned, it will be much easier to convince the senior executives to support these kinds of expenditures.
Preparation is the key to successful deployment of ClearCase, pure and simple. Ask the right questions, gather the right requirements, connect to all of the necessary tools and processes—and you've got it made.