Versioning in Software Configuration Management | SCM Versioning Guide

versioning-in-software-configuration-management

Versioning in Software Configuration Management?

Reference: This article has been take out from Book Called “The Build Master: Microsoft’s Software Configuration Management Best Practices”

Why Worry About Versioning?

  • Having a good version scheme for your software is important for several reasons. The following are the top five things a version scheme allows you to do (in random order):
  • Track your product binaries to the original source files.
  • Re-create a past build by having meaningful labels in your source tree.
  • Avoid “DLL hell” —multiple versions of the same file (library in this case) on a machine.
  • Help your setup program handle upgrades and service packs.
  • Provide your product support and Q/A teams with an easy way to identify the bits they are working with.

So, how do you keep track of files in a product and link them back to the owner? How can you tell that you are testing or using the latest version of a released file? What about the rest of the reasons in the list? This chapter describes my recommendations for the most effective and easiest way to set up and apply versioning to your software. Many different schemes are available, and you should feel free to create your own versioning method.

Ultimately, like most of the other topics in this book, the responsibility to apply versioning to the files in a build tends to fall into the hands of the build team. That might be because it is usually the build team that has to deal with the headaches that come from having a poor versioning scheme. Therefore, it is in their best interest to publish, promote, and enforce a good versioning scheme. If the build team does not own this, then someone who does not understand the full implications of versioning will make the rules. Needless to say, this would not be desirable for anybody involved with the product.

What is the best way to accomplish this? Let’s start with the version number and work our way down.

File Versioning

Every file in a product should have a version number; a four-part number separated by periods such as the one that follows seems to be the established best practice. There are many variations of what each part represents. I will explain what I think is the best way of defining these parts.

<major version>.<minor version>.<build number>.<revision>

Major version— The component owner usually assigns this number. It should be the internal version of the product. It rarely changes during the development cycle of a product release.

Minor version— The component owner usually assigns this number. It is normally used when an incremental release of the product is planned instead of a full feature upgrade. It rarely changes during the development cycle of a product release.

Build number— The build team usually assigns this number based on the build that the file was generated with. It changes with every build of the code.

Revision— The build team usually assigns this number. It can have several meanings: bug number, build number of an older file being replaced, or service pack number. It rarely changes. This number is used mostly when servicing the file for an external release.

Build Number

Each build that is released out of the Central Build Lab should have a unique version stamp (also known as the build number). This number should be incremented just before a build is started. Don’t use a date for a build number or mix dates into a version number simply because there are so many date formats out there that it can be difficult to standardize on one. Also, if you have more than one build on a given date, the naming can get tricky. Stick with an n=n+1 build number. For example, if you release build 100 in the morning and rebuild and release your code in the afternoon, the afternoon build should be build 101. If you were to use a date for the build number, say 010105, what would your afternoon build number be? 010105.1? This can get rather confusing.

How Versioning Affects Setup

Have you ever met someone who reformats his machine every six months because “it just crashes less if I do” or it “performs better?” It might sound draconian, but the current state of component versioning and setup makes starting from scratch a likely solution to these performance issues, which are further complicated by spyware.

Most of the problems occur when various pieces of software end up installing components (DLLs and COM components) that are not quite compatible with each other or with the full set of installed products. Just one incorrect or incorrectly installed DLL can make a program flaky or prevent it from starting up. In fact, DLL and component installation is so important that it is a major part of the Windows logo requirement.

If you are involved in your product’s setup, or if you are involved in making decisions about how to update your components (produce new versions), you can do some specific things to minimize DLL hell and get the correct version of your file on the machine.

Installing components correctly is a little tricky, but with these tips, you can install your components in a way that minimizes the chance of breaking other products on your own.

Install the Correct Version of a Component for the Operating System and Locale
If you have operating system (OS)-specific components, make sure your setup program(s) check which OS you are using and install only the correct components. Also, you cannot give two components the same name and install them in the same directory. If you do, you overwrite the component on the second install on a dual-boot system. Note that the logo requirements recommend that you avoid installing different OS files if possible. Related to this problem is the problem caused when you install the wrong component or typelib for the locale in use, such as installing a U.S. English component on a German machine. This causes messages, labels, menus, and automation method names to be displayed in the wrong language.

Write Components to the Right Places
Avoid copying components to a system directory. An exception to this is if you are updating a system component. For that, you must use an update program provided by the group within Microsoft that maintains the component.

In general, you should copy components to the same directory that you copy the EXE. If you share components between applications, establish a shared components directory. However, it is not recommended that you share components between applications. The risks outweigh the benefits of reduced disk space consumption.

Do Not Install Older Components Over Newer Ones
Sometimes, the setup writer might not properly check the version of an installed component when deciding whether to overwrite the component or skip it. The result can be that an older version of the component is written over a newer version. Your product runs fine, but anything that depends on new features of the newer component fails. Furthermore, your product gets a reputation for breaking other products. We address the issue of whether it makes sense to overwrite components at all. But if you do overwrite them, you don’t want to overwrite a newer version.

“Copy on Reboot” If Component Is in Use
Another common mistake is to avoid dealing with the fact that you cannot overwrite a component that is in use. Instead, you have to set up the file to copy on reboot. Note that if one component is in use, you probably should set up all the components to copy on reboot. If you don’t, and if the user doesn’t reboot promptly, your new components could be mixed with the old ones.

Register Components Correctly; Take Security into Account
Sometimes setups don’t properly register COM components correctly, including the proxy and stub. Note that Windows CE requires that you also register DLLs. Note, too, that when installing DCOM components, you must be vigilant about permissions and security.

Copy Any Component That You Overwrite
It is smart to make a copy of any component that you overwrite before you overwrite it. You won’t want to put it back when you uninstall unless you’re sure that no product installed after yours will need the newer component—a difficult prediction! But by storing the component in a safe place, you make it possible for the user to fix his system if it turns out that the component you installed breaks it. You can let users know about this in the troubleshooting section of your documentation, the README file, or on your Web site. Doing this might not save a call to support, but it does at least make the problem solvable. If the component is not in use, you can move it rather than copying it. Moving is a much faster operation.

Redistribute a Self-Extracting EXE Rather Than Raw Components
If your component is redistributed by others (for instance, your component is distributed with several different products, especially third-party products), it is wise to provide a self-extracting EXE that sets up your component correctly. Make this EXE the only way that you distribute your component. (Such an EXE is also an ideal distribution package for the Web.) If you just distribute raw components, you have to rely on those who redistribute your components to get the setup just right. As we have seen, this is pretty easy to mess up.

Your EXE should support command-line switches for running silently (without a UI) and to force overwriting, even of newer components, so that product support can step users through overwriting if a problem arises.

If you need to update core components that are provided by other groups, use only the EXE that is provided by that group.

Test Setup on Real-World Systems
If you’re not careful, you can install all your setup testing on systems that already happen to have the right components installed and the right registry entries made. Be sure to test on raw systems, on all operating systems, and with popular configurations and third-party software already installed. Also, test other products to make sure they still work after you install your components.

Tagged : / / / / / / / / / / / / / / / / /

How to Select the Right Software version Control Product?

software-version-control-product

Original link: http://www.cmcrossroads.com/cm-articles/275-articles/14286-selecting-the-right-software-version-control-product

Selecting the Right Software Version Control Product Written by Mike Feighner For many years, I worked loyally for the same company where my expertise was restricted to one single software version control tool—the one that was already in place. I was not involved with determining whether the selected tool was appropriate for the company’s needs; my role was to learn it well and use it within the accepted standards, guidelines, and internally approved processes. When I recently found myself back in the job market, I realized that there were many other version control tools in use in the industry. I then began to consult with other engineers in the field and gathered data from them on which version control tools their organizations were using and the selection criteria they used in choosing a version control tool for their organization. This experience opened up a whole new world for me and soon I realized that selecting and implementing the right tools was essential for the success of any software or systems development effort. From this experience, I have drawn up a checklist of version-control-tool criteria to aid an organization in selecting the best tool. Although there are many good descriptions available on the Internet about the many tools currently on the market, I do not recommend one specific tool over the other, because some tools may fit great in one organization, but fail in another. My goal here is to suggest a partial framework for deciding which tool best fits your needs while at the same time adhering to configuration management best practices. First, you will need to define your organization’s goals, which could include any or all of the following: Good documentation should accompany your tool purchase. The tool should be portable to more than one platform. If your organization is spread out over different time zones or even across international borders, your tool should support a multi-site rather than a single-site function. The cost should be affordable. The tool should be easy to use. The tool should easily support branching and merging. The tool should have the ability to lock a file when being edited to prevent two engineers from editing the same file simultaneously. The tool should be able to accurately merge changes between two or more files. The tool should log a history of changes with notes on who made the change and why the change was made. The tool should have the ability to establish immutable baselines. Next, you will need to review your organization’s requirements for software version control and carefully review the various software tools on the market to determine which one best matches your organization’s needs. Some may be better suited for your project than others. Selecting the wrong tool can have devastating effects on your team’s effort. Lack of a good version control tool can be a major cause for delays and problems during your organization’s application development. The project will run over cost and behind schedule and can be prone to risks associated with the manual management and distribution of your project’s dependencies. Unauthorized changes and results will occur, and the customer will not be satisfied. The tool you select should not impede the implementation of configuration management best practices, which serve as a means to add value to the process, improve quality, and increase productivity. The following are some, but not all, of the questions you will need to consider. Documentation Is the tool well documented? Is support documentation available on this tool’s installation and for the tool’s use by both administrators and developers? As a reference manual, the tool’s documentation should adequately describe the tool’s features—each dialog box, tab, field, button, etc. It should answer a user’s questions about completing a specific task in a clear and concise way. Frequently, the user documentation is available in the tool’s help pull-down menu or can be downloaded electronically from the vendor’s website. Portability Is the tool portable? Can it be used on multiple platforms and operating systems? From a business perspective, your software team will be supporting a broad user market occupying various platforms, including Windows, Mac OS, or some flavor of UNIX. Your tool should be compatible on any of these platforms, as each release will simultaneously need a separate version to support each platform of your user base. Multi-site vs. Single Site Is your team located at one location site, or is your team globally distributed across the nation and across different time zones throughout the world? A “single site” constitutes one physical location such as a single building or office. A “multisite” constitutes an organization in more than one office or location in a single time zone, in multiple time zones within one country or in multiple countries. If your organization is spread out over various time zones or even across international borders, your tool should support a multi-site rather than a single-site function. A multi-site project established as a set of several individual independent single-site systems would be prone to added costs and risks associated with the manual management and distribution of the project’s dependencies. Life for a multisite organization would be a lot easier to maintain a single multisite system with access to one shared repository. A single-site organization would be wise to select a single-site system over the additional costs of a multi-site system Cost What are the costs and terms of licensing of the tool? Is it something your organization can afford? Generally, a tool designed for a large organization will have a much larger cost than one designed for a smaller organization. No one should assume paying a higher cost for your tool will solve all of your problems. Even a high cost tool may fall sort of satisfying your organization’s needs. Your decision should consider overall cost and your organization’s needs. Supporting your organization’s needs should never be underfunded. Ease of Use How easy is it to install and deploy the system? Will the tool be dependent on other tools to conduct software builds, or are some of these capabilities already an integral part of the tool? Is this a tool that is easy to use from the first day of installation throughout the entire development lifecycle? Will training and customer support be available? Will the tool require training an in-house administrator dedicated to the administration of the tool? If you are not able to immediately pick up a source code management system and start building your site, odds are it is not entirely user friendly. Ultimately, the key to a successful deployment of a source code management system is reliability and ease-of-use. A tool that is difficult to use will likely conceal the functional benefits that it would otherwise provide. If training is an affordable option for your organization, consider whether it is available through the vendor or through an unbiased third party. For a lower-cost approach in the long term, consider sending a representative from your organization to a vendor training event who will later write up a training program for your own company-based organization. Branching Does the tool accommodate branch creation? The capability to create a branch should allow duplication of an object under revision control. Thus, code modifications can happen securely in parallel along both branches at the same time whether the change involves adding a new requirement or attempting to resolve an issue from an earlier release. The tool you select should support your particular choice of branching strategy, be it by revision or release via a simple copybranch or by creating adelta branch off of the main branch or trunk. Or the tool may go a step further by creating streams that include supporting metadata and workflow automation as an enhancement in managing multiple variants in the code. Branching is one of the most important features to consider in your choice of a good source control management system as it allows you to easily support at the same time the same source code and a parallel subset of the same code being modified securely to support either a new requirement or a bugfix from an earlier release. Merging Does the tool allow merges of changes and assists in resolving conflicts between different edits to the same file? Can a merge be done via a graphical user interface or on a command line? Take into consideration that merging concurrent changes made by different developers can increase the amount of effort to resolve conflicts and achieve a merge safely. The best advice in such cases is to merge little and merge often. File Locking Does the system have a means of preventing concurrent access to the same file? Does it prevent more than one user at a time from writing to the file until the current user either checks in the file or cancels the checkout? History of Changes Does the tool maintain a log of the history of changes? Can the tool display the history of changes graphically, as in a version tree? Does the tool easily identify the current baselined version and list previous baselined versions? A history change log that maintains accurate records facilitates traceability through the code’s lifecycle, from its beginning to its eventual release and beyond. A change history log can trace a change back its origins to who made the change and to the authority who authorized the change. It plays a vital role in baselining the code. This is a basic requirement of any organization wishing to maintain proper controls and compliance. Baselining Baselining, also known as setting a control point for your code, lets you know the exact versions of all source code and other configuration items that were included in a release. Does the tool have a way of baselining the code (be it via labeling, tagging, or snapshots) to a particular version that would allow us to back out and return to the previous baselined version in the event of a problem? Is the baseline immutable? If the tool allows changes to the previously released baseline, it jeopardizes the integrity of the software. A baseline must be locked down to prevent modifications. Any subsequent release should be based on a previously release baseline. Conclusion No one software version control tool can possibly fit every organization’s needs. There is no one size fits all. The right tool should help you safeguard your code and help your process improve productivity and quality. Remember that thorough evaluation and selection of the right tool will require funding, but this vetting must stay within your organization’s budget. Careful selection of the appropriate version control tool will help your firm improve productivity and quality and ensure that you are adhering to industry standards regarding configuration management best practices. About the Author Mike Feighner has more than twenty years’ experience in information technology in the aerospace industry, including more than ten years in configuration management. Mike graduated from San Jose State University with a bachelor’s degree in German and has a master’s degree in political science from the University of Tübingen in Germany and a master’s degree in software engineering from National University.

Tagged : / / / / / / / / / / / / / / /

Software Configuration Management in Pakistan | SCM Practices in Pakistan

software-configuration-management-in-pakistan
Mature CM is cross-business functionality NOT functionality solely within engineering. Software Configuration Management facilitates timely communications; enforces development policies and technical standards along Management of Hand-offs between Environments and Teams efficiently.

The practices and procedures for administering source code, producing software development builds, controlling change, and managing software configurations. Specifically, Software Configuration Management ensures the integrity, reliability and reproducibility of developing software products from conception to release.

I should say CM in Pakistan has been catching up slow but very steadily. There are not many senior people in Pakistan who have dedicated their careers in Configuration Management. Many people moved on to various management roles out of CM after some years of experience. This is due to lack of management opportunities in this area. But, times have changed for good and are getting better. With the growing maturity of CM across the industry, organizations are giving utmost importance to this area and so are hiring people at very senior levels.

I have around 3 years of experience while Interacting CM Professionals internationally and national level; found very strong maturity and awareness. With my experience, I would say Pakistan IT firms still need a broader thinking from CM perspective. In many organizations, people think that CM is just about making builds and controlling source code for projects. We need to educate people about the real importance of Software Configuration Management in any organization. There is a need of clear understanding of various aspects of Configuration Management like Change Management, Incident/Problem Management, Build & release management, Code control/version control , Automated Build management , Parallel development and Continuous integration , Introduction to new tools for software and hardware configurations etc…

CM is much beyond a tool administration or builds management. It does comprise entire life cycle of a project as well as the POST PRODUCTION analysis to improve the process for upcoming projects. It’s a continuous process which not only gives any IT organization a process to boost confidence in delivering quality product with stable code line.

NetSol is vigilant and moving superbly toward innovation and automation through R&D in the field of Configuration Management. Being the CMMI 5 organization; we have implemented excellent Release Management Process that beautifully interacting and entertaining CM Services throughout the organization. We are in process of experimenting Modern tools and discovering best practices for making our process incredibly easy and technically strong. NetSol’s Department of Configuration Management really welcomes newly born organizations and specially those (existing) who want to setup/improve their Configuration Management process and looking for technical improvement mentor; please come up and Consult NetSol with trust.

Tagged : / / / / / / / / / / / / / / /

Best Practices-Software Configuration and Release Management (SCRM)

software-configuration-and-release-management-best-practices

Introduction

The development of software applications is an evolutionary process, moving towards some predetermined end goals. These goals are usually in the form of a Release, either internal or external, to deliver a set of required functionality. Software Release Management is the process of ensuring releases can be reliably planned, scheduled and successfully transitioned (deployed) to Test and Live Environments. Software Release Management is not just about “automating the path to production” although that is certainly an important part. It also about adopting a holistic view of application changes, using the “Release” as the container to ensure that changes are packaged, released and tested in a repeatable and controlled manner. Release Management is often likened to the conductor of an orchestra, with the individual changes to be implemented the various instruments within it. Software Release Management is intrinsically linked with the more well understood and adopted Software Change and Configuration Management disciplines.

This article defines a set of good practices for helping in the successful adoption of Software Release Management. Although this article is about Software Release Management, many of the practices are generic and can also apply to Release Management in its wider sense as described in the IT Infrastructure Library (ITIL) whereby all aspects of hardware installation (e.g. do we need new PCs?), infrastructure upgrade (e.g. do we need to upgrade inter-site links?) and end-user training are considered. In some cases such a release might not include any software artefacts at all.

Defintions

In order to define some good practices it is first worth defining some terms which are used in Software Release Management. The following table lists of set of generic terms which are taken both from service management and application development.

Term

Definition

RFC (Request for Change)

A high-level change request that captures the detail of a change that is to be made to a new or existing application. RFCs are usually decomposed down to lower level work requests or tasks for software development.

CAB (Change Advisory Board)

The collection of stakeholders who review all RFCs at specific intervals to assess whether they should be implemented, assign priorities and allocated them to a Release.

Release

A stable, executable version of a product  intended for deployment to testing and production.

Release Package

A logical container that defines the set of RFCs and Deployment Units (sometimes called Release Units) that are to be included in a Release. It also includes metadata such as the type of release (see Release Type) and its planned dates (see Release Calendar).

Release Type

The type of release that is to be implemented, i.e. Major, Minor, Emergency. Each Release Type will usually have a different workflow.

Release Policy

An organizations published policy that determines under which circumstances different Release Types should be used as well as the standard set of milestones that selecting a particular Release Type implies in the Release Calendar.

Release Calendar

A set of published milestones that details when Releases are planned to transition through the different development, test and production phases.

Baseline

A snapshot of the exact versions of Configuration Items, including executables, libraries, configuration files and documentation that are to be deployed.

Build

An operational version of a product or part of a product. Not all builds are released but builds are typically carried to transform inputs (source code) into executed and installable Deployment Units.

Deployment Unit

A physical, self-contained, installable release of an application.

An example of how these different definitions relate to one another is illustrated in the diagram below:

The Best Practices

The following good practices are based on many years implementing and observing Software Release Management. They are listed in no particular priority or order.

1. Define regular, targeted release dates
You should strictly plan and manage your releases and deliver releases regularly. Create a Release Calendar for each type Product’s Release Package to ensure that release progress is effectively communicated and planned. If a number of releases are being developed in parallel, create and communicate a high-level release milestone plan. The Release Calendar should communicate both internal (development, testing) and external (deployment to live) milestones. The Release Packages and Release Calendar are more easily managed and communicated if the details are kept within a database or workflow tool.

2. Always have a tested back-out plan
For releases that are being deployed to managed live environments you should always have a tested back-out plan. For example, if you deploy a new Internet Banking product release onto the live servers and subsequently find that there are problems with it, there should be a process in place for removing this release and rolling back to the previous one. In this scenario it is desirable that this process is as automatic as possible. The acceptance testing and rollout scenario should be part of the workflow defined for each Release Package.

3. Have a documented Release Policy
Your Software Release Management processes and policies should be clearly defined and documented. This should include the definition of the types of release you will manage, their workflows, the default calendars, as well as roles, responsibilities and artifacts. Usually this type of information is captured in a Release Management Plan. Make sure that this plan clearly states who is responsible for each part of the release process, i.e. who plans and manages the release, who builds and delivers the release internally and who packages and deploys the release externally. All the artefacts that are to be produced as part of the release process, i.e. Release Plan, Release Notes, Installation Instructions, should be clearly documented (and example templates given) along with who is responsible for generating them.

4. Construct Deployment Units as early as possible
Every time you build your application you should be constructing Deployment Units with the potential to be installed, for example a J2EE .EAR file or a Windows .MSI package. These Deployment Units might not be released beyond the development team but the point is that the build, packaging and installation process is proven early and at each phase.

5. Use an independent team to construct all external releases
If your team is very small then the developers might be able to carry out the build and construct the Deployment Unit. However, for any medium to large size product it is desirable to have a separate release team. This team usually manages the build process and packages up the results of the build into the Deployment Unit. They usually deploy internally (and sometimes externally) or pass the deployment unit to a separate deployment team. The release team is also responsible for creating the logical Release Package’s and communicating release dates.

6. All deployments should be performed by a team independent of the Development team
Developers should not be allowed to transition Deployment Units into a live environment. There is a potential conflict of interests in this situation. For audit ability and traceability it is better to have a separate team deploy the release to Live (and usually Acceptance Testing)

7. Test the deployment process at least once before deploying to Live
The deployment process should be tested at least once before any release is put into a live environment. This is normally carried out by having an Acceptance Test environment that mimics the live environment and is controlled in the same way.

8. Automate as much as possible – use integrated tools for Configuration, Change Management and Deployment Management
Software Release Management can be a repetitive and error prone manual process, therefore as much as possible should be automated. At the very least, the inputs and outputs of the release process (including the build components and release documentation) should be versioned using a Configuration Management tool (e.g Perforce,Subversion,Clearcase,TFS,etc) A Change Management tool can be used for controlling the content of the release and making Requests For Changes (RFCs) to it. A Deployment Management tool can be used to move the release to different environments or to install onto multiple desktop machines. Obviously, this all works best if these tools are integrated through to the Release Management process and its supporting tool(s).

9. Use a mature Software Configuration Management process and tool to support the development of multiple releases in parallel
When you are developing, building and deploying multiple releases in parallel it is critical that you have a Software Configuration Management tool that supports parallel development. Such tools are sometimes high-end, expensive toolsets (not open-source  but they can significantly help to automate and reduce errors in the otherwise manual branching and merging process.

10. Link all release documentation and scripts to your Deployment Unit
When a release is deployed you should be able to identify from the Deployment Unit all the related hardware and software that is required to support the release.  The Release Package is a good container for managing these relationships. The Release Package can either relate all this together in documentation form or better still reference entries in a database. Such a database should identify for each product that is built and released: the required hardware, supporting third-party software and the Installation and Configuration instructions. In the
ITIL world such a database is often called the CMDB (Configuration Management Database).

Tagged : / / / / / / / / / / / / / /

Power Point PPT: Introduction To Software Configuration Management

software-configuration-management-introduction

Power Point PPT: Introduction To Software Configuration Management

 

Tagged : / / / / / / / / / / / / / / / / / /

Power Point PPT: Software Configuration Management And CVS

software-configuration-management-and-cvs

Power Point PPT: Software Configuration Management And CVS

Tagged : / / / / / / / / / / / / /

Power Point PPT: Why Software Configuration Management – Prsesentation

why-software-configuration-management

Power Point PPT: Why Software Configuration Management

 

Tagged : / / / / / / / / / / / / / / / / / / /

Workforce Management Software Helps Call Centers Save Money

workforce-management

One way to increase revenues in your inbound call center might be via workforce management software.

For call centers that realize revenue by answering calls (be they catalogues, reservation centers, what have you), workforce management automation can help reduce queue times and improve service, thereby reducing the number of abandoned calls and increasing revenue calls completed.

These call centers can increase revenues by tens of thousands of dollars per year in addition to the cost savings.

And since cost is a prime consideration, you’ll want to look at the SaaS (News – Alert)-based model.

Do be careful, though: “Often vendors who sell on-premise software may offer a hosted model for on-demand options and often misleadingly call it SaaS-based software,” say officials of Monet Software, which offers cloud-based WFM. “However, sometimes it’s simply a hosted client server application on a server at the vendor’s site, providing an application that was not originally designed to be hosted and delivered, with a few changes, over the Web via a single, dedicated server.”

You’ll be able to tell such impostors as they’ll almost always lack multi-tenant architecture and require separate servers and installations for each customer. In the end, Monet officials warn, they’re “much more costly and less scalable, and also usually require support for multiple releases, which is very resource intensive.”

Genuinely useful SaaS workforce management software, however, is a boon to users. A product such as Monet WFM Live uses a new multi-tenant architecture “designed to deliver Web-based applications at the lowest possible cost,” company officials say, focusing on “fast set up, low operating costs through shared services, highest security for Web-based deployment and high performance and scalability through the scaling of computer resources also called ‘elastic cloud computing.'”

This is nicely cost-effective, as it ensures available computing capacity only when you need it, at the lowest possible cost.

With SaaS there’s no large upfront investment for software and hardware either, it’s usually offered via a low monthly subscription fee that includes support, maintenance and upgrades.

And of course with the SaaS provider managing the IT infrastructure, costs are lowered by avoiding IT participation time for hardware and software issues as well as the personnel resources required for IT management. These “hidden costs” for hardware replacements, upgrades, and IT operation resources are typical for other premise-based software.

Tagged : / / / / / / / / / / / / / / / / / / / /

Click & Download TOP useful Freeware software

freeware-software

Click & Download TOP useful Freeware software

Office

OpenOffice – office suite
PC Suite 602 – office suite
AbiWord – text editor
Atlantis Nova – text editor
Microsoft PowerPoint Viewer  – power point files viewer
Adobe Reader – pdf reader
Foxit PDF Reader – pdf reader
PDFCreator – create pdf documents
Doc Convertor – document convertor
Convert – unit convertor
Converber – unit convertor
Sunbird – calendar/organizer
EssentialPIM Free – calendar/organizer
PhraseExpress – speed up your writing
ATnotes – create notes on the desktop

Archive managers

7-Zip – compression program
IZArc – compression program
TugZIP – compression program
CabPack – compression program
Universal Extractor – extract files from any type of archive

Internet

Firefox – web browser
Internet Explorer– web browser
Maxthon – web browser
Opera – web browser
Avant Browser – web browser
Thunderbird – email client
PopTray – check for emails
Free Download Manager – download manager
FlashGet – download manager
WellGet – download manager
Download Master – download manager
WGET – commandline download manager
HTTrack – offline browser
WebReaper – offline browser
Yeah Reader – RSS reader
GreatNews – RSS reader
RSSOwl – RSS reader

P2P  this is sharing files on your computer with someone else.

?Torrent – torrent client
Azureus – torrent client
BitComet – torrent client
ABC – torrent client
BitTornado – torrent client
eMule – p2p client
SoulSeek – p2p client
Shareaza – p2p client
DC++ – Direct Connect network client
PeerGuardian – IP blocker

Chat

Miranda – chat client
MSN Messenger – chat client
Yahoo Messenger – chat client
QIP – chat client
Gaim – chat client
JAJC – chat client
HydraIRC – IRC client
Talkative IRC – IRC client
IceChat – IRC client
Skype – VOIP client
Google Talk – VOIP client
VoipStunt – VOIP client
Gizmo – VOIP client
Wengo – VOIP client

Security

AVG Free – antivirus
Avast Home Free – antivirus
AntiVir PersonalEdition – antivirus
BitDefender Free – antivirus
ClamWin – antivirus
CyberDifender – Internet Security Suite
Ad-aware – anti-spyware
Spybot: Search & Destroy – anti-spyware
Windows Defender – anti-spyware
SpywareBlaster – anti-spyware
Spyware Terminator – anti-spyware
Tootkit Reveaker  – rootkit detection utility
Winpooch – system protection
HiJack Free – system protection
HighJackThis – hijackers detector and remover
Kerio Personal Firewall – firewall
Sygate Personal Firewall – firewall
ZoneAlarm – firewall
AxCrypt – file encryption
Simple File Shredder – securely delete files
PuTTy – SSH client
KeePass – password manager
LockNote – password manager
nPassword – password manager
Microsoft Baseline Security Analyzer – identify security misconfigurations

Network

Hamachi – VPN client
RealVNC – remote control
UltraVNC – remote control
Ethereal – local area network administration
The Dude – network administration
Wireshark – network administration
Angry IP Scanner – IP scanner
IP-Tools – IP scanner
Free Port Scanner – IP scanner
NetMeter – network bandwidth monitoring

Servers

FileZilla – FTP client
FileZilla Server – FTP server
EFTP – FTP client/server
XAMPP – integrated server package of Apache, mySQL, PHP and Perl
WAMP – Apache, PHP5 and MySQL server

Audio

Foobar2000 – audio player
WinAmp – audio player
1by1 – audio player
JetAudio – audio player
XMPlay – audio player
Xion – audio player
Apollo – audio player
MediaMonkey – music organizer
The GodFather – music organizer
dBpowerAMP – audio converter
Audacity – audio converter
WavePad – audio converter
Kristal Audio Engine – audio editor
Exact Audio Copy – CD ripper
Audiograbber – CD ripper
CDex – CD ripper
Mp3 Tag Tools – tag editor
Mp3tag – tag editor
Taggin? MP3 – tag editor
Monkey?s Audio – APE compressor/decompressor
mpTrim – mp3 editor
WavTrim – wave editor
EncSpot Basic – analyse mp3 files

Video

Windows Media Player – audio/video player
VLC – video player
Media Player Classic – video player
MV2Player – video player
CrystalPlayer 1.95 – video player
Zoom Player – video player
GOM Player – video player
viPlay – video player
DSPlayer – video player
VirtualDub – video editor
CamStudio – video screen recording
AviSplit – Avi splitter
Video mp3 Extractor – rip audio from video files
Free iPod Converter – convert all popular video formats to iPod video
MediaPortal – turning your PCinto a Media Center
The FilmMachine

Image

Gimp – image editor
PhotoFiltre – image editor
Paint.net – image editor
ArtRage – image editor
Artweaver – image editor
IrfanView – image viewer
Picasa – image viewer
XnView – image viewer
FastStone Image Viewer – image viewer
FuturixImager – image viewer
Easy Thumbnails – create thumbnails from images
JoJoThumb – create thumbnails from images
iWebAlbum – create web photo albums
JAlbum – create web photo albums
3D Box Shot Maker – design quality box shot
FastStone Capture – screen capture
WinSnap – screen capture

3D

Blender3D – 3D renderer
3Delight Free – 3D renderer
SketchUp – 3D modeling
Maya Learning Edition – 3D modeling

Developers

AutoIt – task automation
SciTE4AutoIt3 – text editor for AutoIt
AutoHotkey – task automation
PHP Designer – PHP editor
Notepad++ – text editor
ConTEXT Editor – text editor
PSPad – text editor
FoxEditor – text editor
Crimson Editor – source code editor
Elfima Notepad – text editor
Notepad2 – text editor
Nvu – HTML editor
Alleycode – HTML editor
BlockNote – web page editor
Weaverslave – web page editor

CD/DVD

DeepBurner – CD/DVD burner
CDBurner XP Pro – CD/DVD burner
BurnAtOnce – CD/DVD burner
Express Burn – CD/DVD burner
Zilla CD-DVD Rip?n?Burn – CD/DVD burner
ImgBurn – ISO, BIN burner
Daemon tools – virtual CD/DVD
DVD Decrypter – DVD ripper
DVD Shrink – DVD ripper
Nero CD-DVD Speed – CD/DVD info and quality test

Codecs

GSpot – codec information
AC3Filter – audio codec
Xvid – video codec
QuickTime Alternative – video codec
Real Alternative – video codec
K-Lite Codec Pack – all codecs

System Ulilities

CCleaner – system cleaner
xp-AntiSpy – OS setup
jv16 Powertools – system utilities
XP SysPad – system monitoring utility
What?s Running – process guard
Registrar Lite – registry editor
WinIPConfig – replacement for ?ipconfig.exe? and ?route.exe?
Unlocker – file eraser
Eraser – secure file eraser
Undelete Plus – file recovery
freeCommander – file manager
ExplorerXP – file manager
Duplicate File Finder – find all duplicate files
Ant Renamer – file renaming
ReNamer – file renaming
Icons From File – icos extractor
Chaos MD5 – MD5 generator
HashTab – MD5, SHA1 and CRC-32 file hashes
Rainlendar Lite – desktop calendar
Weather Watcher – weather firecast
Subtitle Workshop – subtitles editor
Ant Movie Catalog – movie organizer
Disclib – CD organizer
Dexpot – virtual desktops
DriveImage XML – create partition images
MozBackup – backup and restore bookmarks, etc.
SyncBack – system backup
Atomic Cock Sync – syncronize your clock
Citrus Alarm Clock – alarm clock
TaskSwitchXP – Alt-Tab replacement
Launchy – application launcher
allSnap – make all windows snap
Sysinternals Tools – various system tools
StrokeIt – mouse gestures
Net Profiles – create profiles of your network settings
ResourceHacker – view, modify, rename, add, delete
Java Runtime Environment – java for Windows

UI Enhancements

RocketDock  – application launcher
AveDesk – desktop enhancer
IconPhile – customize windows?s system icons
CursorXP Free – change mouse cursors
MacSound – volume control
LClock – Windows Longhorn clock
Y?z Dock – application launcher
Y?z Shadow – shadow effect to the windows
Y?z Toolbar – change the toolbar icons in Explorer and Internet Explorer
Taskbar Shuffle – rearrange the programs on the taskbar by dragging
Visual Task Tips – thumbnail preview image for each task in the taskbar
Badges  – put badges on any folder or file
Folderico – change icons of the folders
Folder Marker – mark your folders
Folder2MyPC – add favourite locations to My Computer
Microsoft TweakUI – system settings
BricoPacks – shell packs
ShellPacks – shell packs
Tango Shell Patcher – shell patcher
XPize – GUI enhancer
Vista Transformation Pack  – complete visual style
Vista Sound Scheme – Windows Vista sound scheme
Royale Theme – visual style

Hardware monitoring/Benchmarking

CPU-Z – cpu information
CrystalCPUID – cpu information
Central Brain Identifier – cpu information
Everest – system information
SiSoft Sandra – system information
SpeedFan – hardware monitor
Memtest86 – memory test
PowerMax – HDD test
3Dmark 06 – 3D game performance benchmark
Aquamark – performance benchmark
rthdribl – 3D benchmark
Fraps – 3D benchmark, fps viewer and screen recorder
Prime 95 – cpu benchmarking
SuperPI – cpu benchmarking
CPU Rightmark – cpu overclock
Core Temp – cpu temperature
ATiTool – video overclock
ATI Tray Tools – Radeon tweaker
aTuner – GeForce and Radeontweaker
RivaTuner – video overclock
Nokia Monitor Test – monitor adjustmets
UDPixel – fix dead pixels

Games

123 Free Solitaire  – solitaire games collection
Arcade Pack – classic arcade games
Live For Speed – online racing simulator
Enigma – puzzle game
Freeciv – multiplayer strategy game
Tux Racer – race down steep, snow-covered mount?ins

Education

SpeQ Mathematics  – mathematics program
Dia – diagram creation program
Google Earth – explore the world
NASA World Wind – 3D virtual globe
Celestia – explore the space
Stellarium – planetarium

Miscellaneous

nLite – Build your own custom Windows disk.
VirtualPC – create virtual machines
grabMotion – webcam capture
iDailyDiary – simple page-for-a-day diary
Pivot Stickfigure Animator – create stick-figure animations
Wink – create presentations
Scribus – professional page layout
FreeMind – mind mapping software
Windows Live Writer – WYSIWYG blog authoring

Wallpapers

Michael Swanson  – 1920 x 1200; 1600 x 1200; amazing wallpapers
Mikhail Arkhipov – 1920 x 1200; 1600 x 1200; amazing wallpapers

Tagged : / / / / / / / / / / / / / / / /

Best Practices in Software Configuration Management – SCM Best Practices Guide

scm-best-practices

Best Practices in Software Configuration Management

Abstract
When deploying new SCM (software configuration management) tools,
implementers sometimes focus on perfecting fine-grained activities, while
unwittingly carrying forward poor, large-scale practices from their previous jobs or
previous tools. The result is a well-executed blunder. This paper promotes some
high-level best practices that reflect the authors’ experiences in deploying SCM.

1. Introduction
“A tool is only as good as you use it,” the saying goes. As providers of software configuration management (SCM) tools and consultants to software companies, we
are often asked for sound advice on SCM best practices – that is, how to deploy SCM software to the maximum advantage. In answering these requests we have a bounty of direct and indirect SCM experience from which to draw. The direct experience comes from having been developers and codeline managers ourselves; the indirect experience comes from customer reports of successes and failures with our product (Perforce) and other SCM tools.
The table below lists six general areas of SCM deployment, and some coarse-grained best practices within each of those areas. The following chapters explain each item.

Workspaces, where
developers build, test, and
debug.
· Don’t share workspaces.
· Don’t work outside of managed workspaces.
· Don’t use jello views.
· Stay in sync with the codeline.
· Check in often.
Codelines, the canonical sets
of source files.
· Give each codeline a policy.
· Give each codeline an owner.
· Have a mainline.
Branches, variants of the
codeline.
· Branch only when necessary.
· Don’t copy when you mean to branch.
· Branch on incompatible policy.
· Branch late.
· Branch, instead of freeze.
Change propagation, getting
changes from one codeline to
another.
· Make original changes in the branch that has
evolved the least since branching.
· Propagate early and often.
· Get the right person to do the merge.
Builds, turning source files
into products.
· Source + tools = product.
· Check in all original source.
· Segregate built objects from original source.
· Use common build tools.
· Build often.
· Keep build logs and build output.
Process, the rules for all of
the above.
· Track change packages.
· Track change package propagations.
· Distinguish change requests from change
packages.
· Give everything and owner.
· Use living documents.

2. The Workspace
The workspace is where engineers edit source files, build the software components they’re working on, and test and debug what they’ve built. Most SCM systems have some notion of a workspace; sometimes they are called “sandboxes”, as in Source Integrity, or “views”, as in ClearCase and Perforce. Changes to managed SCM repository files begin as changes to files in a workspace. The best practices for workspaces include:· Don’t share workspaces. A workspace should have a single purpose, such as an edit/build/test area for a single developer, or a build/test/release area for a product release. Sharing workspaces confuses people, just as sharing a desk does. Furthermore, sharing workspaces compromises the SCM system’s ability to track activity by user or task. Workspaces and the disk space they occupy are cheap; don’t waste time trying to conserve them.· Don’t work outside of managed workspaces. Your SCM system can only track work in progress when it takes place within managed workspaces. Users working outside of workspaces are beached; there’s a river of information flowing past and they’re not part of it. For instance, SCM systems generally use workspaces to facilitate some of the communication among developers working on related tasks. You can see what is happening in others’ workspaces, and they can see what’s going on in yours. If you need to take an emergency vacation, your properly managed workspace may be all you can leave behind. Use proper workspaces.
· Don’t use jello views. A file in your workspace should not change unless youexplicitly cause the change. A “jello view” is a workspace where file changes are
caused by external events beyond your control. A typical example of a jello view is a workspace built upon a tree of symbolic links to files in another workspace –
when the underlying files are updated, your workspace files change. Jello views are a source of chaos in software development. Debug symbols in executables
don’t match the source files, mysterious recompilations occur in supposedly trivial rebuilds, and debugging cycles never converge – these are just some of the
problems. Keep your workspaces firm and stable by setting them up so that users have control over when their files change.· Stay in sync with the codeline. As a developer, the quality of your work depends on how well it meshes with other peoples’ work. In other words, as changes are checked into the codeline, you should update your workspace and integrate those changes with yours. As an SCM engineer, it behooves you to make sure this workspace update operation is straightforward and unencumbered with tricky or time-consuming procedures. If developers find it fairly painless to update their workspaces, they’ll do it more frequently and integration problems won’t pile up at project deadlines.
· Check in often. Integrating your development work with other peoples’ work also requires you to check in your changes as soon as they are ready. Once you’ve
finished a development task, check in your changed files so that your work is available to others. Again, as the SCM engineer, you should set up procedures that encourage frequent check-ins. Don’t implement unduly arduous validation procedures, and don’t freeze codelines (see Branching, below). Short freezes are bearable, but long freezes compromise productivity. Much productivity can be wasted waiting for the right day (or week, or month) to submit changes.

3. The Codeline
In this context, the codeline is the canonical set of source files required to produce your software. Typically codelines are branched, and the branches evolve into variant
codelines embodying different releases. The best practices with regard to codelines are:
· Give each codeline a policy. A codeline policy specifies the fair use and permissible check-ins for the codeline, and is the essential user’s manual for
codeline SCM. For example, the policy of a development codeline should state that it isn’t for release; likewise, the policy of a release codeline should limit
changes to approved bug fixes.1 The policy can also describe how to document changes being checked in, what review is needed, what testing is required, and
the expectations of codeline stability after check-ins. A policy is a critical component for a documented, enforceable software development process, and a
codeline without a policy, from an SCM point of view, is out of control.· Give each codeline an owner. Having defined a policy for a codeline, you’ll soon
encounter special cases where the policy is inapplicable or ambiguous. Developers facing these ambiguities will turn to the person in charge of the
codeline for workarounds. When no one is in charge, developers tend to enact their own workarounds without documenting them. Or they simply procrastinate
because they don’t have enough information about the codeline to come up with a reasonable workaround. You can avoid this morass by appointing someone to
own the codeline, and to shepherd it through its useful life. With this broader objective, the codeline owner can smooth the ride over rough spots in software
development by advising developers on policy exceptions and documenting them.

· Have a mainline. A “mainline,” or “trunk,” is the branch of a codeline that evolves forever. A mainline provides an ultimate destination for almost all
changes – both maintenance fixes and new features – and represents the primary, linear evolution of a software product. Release codelines and development
codelines are branched from the mainline, and work that occurs in branches is propagated back to the mainline.

IMAGE  – 1

Figure 1 shows a mainline (called “main”), from which several release lines (“ver1”, “ver2” and “ver3”) and feature development lines (“projA”, “projb”, and
“projC”) have been branched. Developers work in the mainline or in a feature development line. The release lines are reserved for testing and critical fixes, and
are insulated from the hubbub of development. Eventually all changes submitted to the release lines and the feature development lines get merged into the
mainline. The adverse approach is to “promote” codelines; for example, to promote a development codeline to a release codeline, and branch off a new development
codeline. For example, Figure 2 shows a development codeline promoted to a release codeline (“ver1”) and branched into another development codeline
(“projA”). Each release codeline starts out as a development codeline, and development moves from codeline to codeline.

IMAGE – 2

The promotion scheme suffers from two crippling drawbacks: (1) it requires the policy of a codeline to change, which is never easy to communicate to everyone;
(2) it requires developers to relocate their work from one codeline to another, which is error-prone and time-consuming. 90% of SCM “process” is enforcing
codeline promotion to compensate for the lack of a mainline. Process is streamlined and simplified when you use a mainline model. With a
mainline, contributors’ workspaces and environments are stable for the duration of their tasks at hand, and no additional administrative overhead is incurred as
software products move forward to maturity.

4. Branching
Branching, the creation of variant codelines from other codelines, is the most problematic area of SCM. Different SCM tools support branching in markedly
different ways, and different policies require that branching be used in still more different ways. We found the following guidelines helpful when branching (and
sometimes when avoiding branching):·

Branch only when necessary. Every branch is more work – more builds, more changes to be propagated among codelines, more source file merges. If you keep this in mind every time you consider making a branch you may avoid sprouting unnecessary branches.
· Don’t copy when you mean to branch. An alternative to using your SCM tool’s branching mechanism is to copy a set of source files from one codeline and
check them in to another as new files. Don’t think that you can avoid the costs of branching by simply copying. Copying incurs all the headaches of branching –
additional entities and increased complexity – but without the benefit of your SCM system’s branching support. Don’t be fooled: even “read-only” copies
shipped off to another development group “for reference only” often return with changes made. Use your SCM system to make branches when you spin off parts
or all of a codeline.
· Branch on incompatible policy. There is one simple rule to determine if a codeline should be branched: it should be branched when its users need different
check-in policies. For example, a product release group may need a check-in policy that enforces rigorous testing, whereas a development team may need a
policy that allows frequent check-ins of partially tested changes. This policy divergence calls for a codeline branch. When one development group doesn’t
wish to see another development group’s changes, that is also a form of incompatible policy: each group should have its own branch.
· Branch late. To minimize the number of changes that need to be propagated from one branch to another, put off creating a branch as long as possible. For
example, if the mainline branch contains all the new features ready for a release, do as much testing and bug fixing in it as you can before creating a release
branch. Every bug fixed in the mainline before the release branch is created is one less change needing propagation between branches.
· Branch instead of freeze. On the other hand, if testing requires freezing a codeline, developers who have pending changes will have to sit on their changes
until the testing is complete. If this is the case, branch the codeline early enough so that developers can check in and get on with their work.

5. Change Propagation
Once you have branched codelines, you face the chore of propagating file changes across branches. This is rarely a trivial task, but there are some things you can do to
keep it manageable.
· Make original changes in the branch that has evolved the least since branching. It is much easier to merge a change from a file that is close to the common
ancestor than it is to merge a change from a file that has diverged considerably. This is because the change in the file that has diverged may be built upon
changes that are not being propagated, and those unwanted changes can confound the merge process. You can minimize the merge complexity by making
original changes in the branch that is the most stable. For example, if a release codeline is branched from a mainline, make a bug fix first in the release line and
then merge it into the mainline. If you make the bug fix in the mainline first, subsequently merging it into a release codeline may require you to back out
other, incompatible changes that aren’t meant to go into the release codeline.
· Propagate early and often. When it’s feasible to propagate a change from one branch to another (that is, if the change wouldn’t violate the target branch’s
policy), do it sooner rather than later. Postponed and batched change propagations can result in stunningly complex file merges.
· Get the right person to do the merge. The burden of change propagation can be lightened by assigning the responsibility to the engineer best prepared to resolve
file conflicts. Changes can be propagated by (a) the owner of the target files, (b) the person who make the original changes, or (c) someone else. Either (a) or (b)
will do a better job than (c).

6. Builds
A build is the business of constructing usable software from original source files. Builds are more manageable and less prone to problems when a few key practices are
observed:
· Source + tools = product. The only ingredients in a build should be source files and the tools to which they are input. Memorized procedures and yellow stickies
have no place in this equation. Given the same source files and build tools, the resulting product should always be the same. If you have rote setup procedures,
automate them in scripts. If you have manual setup steps, document them in build instructions. And document all tool specifications, including OS, compilers, include files, link libraries, make programs, and executable paths.
· Check in all original source. When software can’t be reliably reproduced from the same ingredients, chances are the ingredient list is incomplete. Frequently
overlooked ingredients are makefiles, setup scripts, build scripts, build instructions, and tool specifications. All of these are the source you build with.
Remember: source + tools = product.
· Segregate built objects from original source. Organize your builds so that the directories containing original source files are not polluted by built objects.
Original source files are those you create “from an original thought process” with a text editor, an application generator, or any other interactive tool. Built objects
are all the files that get created during your build process, including generated source files. Built objects should not go into your source code directories.
Instead, build them into a directory tree of their own. This segregation allows you to limit the scope of SCM-managed directories to those that contain only
source. It also corrals the files that tend to be large and/or expendable into one location, and simplifies disk space management for builds.
· Use common build tools. Developers, test engineers, and release engineers should all use the same build tools. Much time is wasted when a developer
cannot reproduce a problem found in testing, or when the released product varies from what was tested. Remember: source + tools = product.
· Build often. Frequent, end-to-end builds with regression testing (“sanity” builds) have two benefits: (1) they reveal integration problems introduced by check-ins,
and (2) they produce link libraries and other built objects that can be used by developers. In an ideal world, sanity builds would occur after every check-in, but
in an active codeline it’s more practical to do them at intervals, typically nightly. Every codeline branch should be subject to regular, frequent, and complete builds
and regression testing, even when product release is in the distant future.
· Keep build logs and build outputs. For any built object you produce, you should be able to look up the exact operations (e.g., complete compiler flag and link
command text) that produced the last known good version of it. Archive build outputs and logs, including source file versions (e.g., a label), tool and OS
version info, compiler outputs, intermediate files, built objects, and test results, for future reference. As large software projects evolve, components are handed
off from one group to another, and the receiving group may not be in a position to begin builds of new components immediately. When they do begin to build
new components, they will need access to previous build logs in order to diagnose the integration problems they encounter.

7. Process
It would take an entire paper, or several papers, to explore the full scope of SCM process design and implementation, and many such papers have already been written. Furthermore, your shop has specific objectives and requirements that will be reflected in the process you implement, and we do not presume to know what those are. In our experience, however, some process concepts are key to any SCM implementation:
· Track change packages. Even though each file in a codeline has its revision history, each revision in its history is only useful in the context of a set of related
files. The question “What other source files were changed along with this particular change to foo.c?” can’t be answered unless you track change
packages, or sets of files related by a logical change. Change packages, not individual file changes, are the visible manifestation of software development.
Some SCM systems track change packages for you; if yours doesn’t, write an interface that does.
· Track change package propagations. One clear benefit of tracking change packages is that it becomes very easy propagate logical changes (e.g., bug fixes)
from one codeline branch to another. However, it’s not enough to simply propagate change packages across branches; you must keep track of which
change packages have been propagated, which propagations are pending, and which codeline branches are likely donors or recipients of propagations.
Otherwise you’ll never be able to answer the question “Is the fix for bug X in the release Y codeline?” Again, some SCM systems track change package
propagations for you, whereas with others you’ll have to write your own interface to do it. Ultimately, you should never have to resort to “diffing” files to
figure out if a change package has been propagated between codelines.

· Distinguish change requests from change packages. “What to do” and “what was done” are different data entities. For example, a bug report is a “what to do”
entity and a bug fix is a “what was done” entity. Your SCM process should distinguish between the two, because in fact there can be a one-to-many
relationship between change requests and change packages.
· Give everything an owner. Every process, policy, document, product, component, codeline, branch, and task in your SCM system should have an
owner. Owners give life to these entities by representing them; an entity with an owner can grow and mature. Ownerless entities are like obstacles in an ant trail
– the ants simply march around them as if they weren’t there.
· Use living documents. The policies and procedures you implement should be described in living documents; that is, your process documentation should be as
readily available and as subject to update as your managed source code. Documents that aren’t accessible are useless; documents that aren’t updateable
are nearly so. Process documents should be accessible from all of your development environments: at your own workstation, at someone else’s
workstation, and from your machine at home. And process documents should be easily updateable, and updates should be immediately available.

8. Conclusion
Best practices in SCM, like best practices anywhere, always seem obvious once you’ve used them. The practices discussed in this paper have worked well for us, but
we recognize that no single, short document can contain them all. So we have presented the practices that offer the greatest return and yet seem to be violated more
often than not. We welcome the opportunity to improve this document, and solicit both challenges to the above practices as well as the additions of new ones.

10. References
Berczuk, Steve. “Configuration Management Patterns”, 1997. Available at
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ConfigurationManagementPatterns.
Compton, Stephen B, Configuration Management for Software, VNR Computer
Library, Van Nostrand Reinhold, 1993.
Continuus Software Corp., “Work Area Management”, Continuus/CM: Change
Management for Software Development. Available at
http://www.continuus.com/developers/developersACE.html.
Dart, Susan, “Spectrum of Functionality in Configuration Management Systems”,
Software Engineering Institute, 1990. Available at
http://www.sei.cmu.edu/technology/case/scm/tech_rep/TR11_90/TOC_TR11_90.html

Jameson, Kevin, Multi Platform Code Management, O’Reilly & Associates, 1994
Linenbach, Terris, “Programmers’ Canvas: A pattern for source code management”
1996. Available at http://www.rahul.net/terris/ProgrammersCanvas.htm.
Lyon, David D, Practical CM, Raven Publishing, 1997
McConnell, Steve, “Best Practices: Daily Build and Smoke Test”,
IEEE Software, Vol. 13, No. 4, July 1996
van der Hoek, Andre, Hall, Richard S., Heimbigner, Dennis, and Wolf, Alexander L.,
“Software Release Management”, Proceedings of the 6th European Software
Engineering Conference, Zurich, Switzerland, 1997.

10. Author

Laura Wingerd
Perforce Software, Inc.
wingerd@perforce.com
Christopher Seiwald
Perforce Software, Inc.
seiwald@perforce.com

Tagged : / / / / / / / / / / / / / / / / / / / / / / / / / /