Tag: Management

Build Management Recommendation – Build Management Guidance

by scmgalaxy KBuild ManagementLeave a Comment on Build Management Recommendation – Build Management Guidance

build-management-recommendation

Recommendation from Microsoft’s Software Configuration Management Best Practices

Build Management Recommendation

Recommendation for Defining a Build

  • Define terms in your development process, and keep a glossary of them on an internal build Web page. If you like, standardize on the definitions in this chapter.
  • Clean build your complete product at least once per week, or every day if possible.
  • Use incremental builds on a daily basis if clean builds are not possible or practical.
  • Start charting the quality of your product, and post it where everyone involved in the project can see it.
  • Release LKG (or IDW) builds weekly; then switch to daily releases toward the end of the shipping cycle.
  • Follow the Software Development Flow diagram.

Recommendation for Source Tree Configuration for Multiple Sites and Parallel (Multi-Version) Development Work

  • Create the mainline (public) and virtual build labs (private) codelines.
  • Make sure the mainline is pristine and always buildable and consumable. Create shippable bits on a daily basis. Use consistent, reliable builds.
  • Build private branches in parallel with the main build at a frequency set by the CBT.
  • Use consistent reverse and forward integration criteria across teams.
  • Be aware that dev check-ins are normally made only into a private branch or tree, not the mainline.
  • Know that check-ins into a private branch are only reverse integrated (RId) into main when stringent, division-wide criteria are met.
  • Use atomic check-ins (RI) from private into main. Atomic means all or nothing. You can back out changes if needed.
  • Make project teams accountable for their check-ins, and empower them to control their build process with help from the CBT.
  • Configure the public/private source so that multisite or parallel development works.
  • Optimize the source tree or branch structure so that you have only one branch per component of your product.

Recommendation for Daily, Not Nightly, Builds

  • Hire a consulting firm to come in and review your processes and tools.
  • Start your build during the day, not during the evening.
  • Publish the build schedule on an internal Web site.
  • Release daily builds as sure as the sun comes up, but make sure they are quality, usable builds. Don’t just go through the motions.
  • Discourage build breaks by creating and enforcing consequences.

Recommendation for The Build Lab and Personnel

  • Set up a build lab if you do not already have one.
  • Purchase all necessary hardware, and do not skimp on quality or number of machines.
  • Keep the lab secure.
  • Show a lot of appreciation for your build team. They have a difficult job that requires a special skill set and personality to be successful.

Recommendation for Build Tools and Technologies

  • Use command-line builds for the central build process.
  • Use Make or ANT for non-Microsoft platforms or tools.
  • Use MSBuild for .NET builds.
  • Use VCBuild for non-.NET builds.
  • Write your scripts in an easy language such as Perl or Batch files.
  • Learn XML because it is ubiquitous.

Recommendation for SNAP Builds—aka Integration Builds

  • Develop your own integration build tool to be used as a precheck-in build test to the golden source trees, or wait for Microsoft to release a tool similar to this one. Keep the points in this chapter in mind when you’re building this “silver bullet.”
  • If you deploy a Virtual Build Lab process, require that the VBLs use a SNAP system to stay in sync with the Central Build Lab. This is the whole concept of an integration build system such as this.
  • Do not rely on the SNAP system as your mainline build tool. Although I mention that some groups at Microsoft use this tool as their Central Build Team build tool, this can be a little problematic because the check-in queues can get really backed up.
  • Understand that no magic tool is out there to do your work for you when it comes to builds and merging code. But SNAP is a good tool, and some groups at Microsoft cannot live without it.
  • Make sure you have all the other processes down in this book before trying to roll out a SNAP system. These processes include source tree configuration, build schedules, versioning, build lab, and so on.

Recommendation for The Build Environment

Here is a short list of what the build environment example in this chapter is about. If everyone is using the same batch files to launch a build environment, re-creating a build will be less painful.

  • Keep the build environment consistent, and control it through the Central Build Team’s intranet Web page.
  • Use batch file commands similar to the ones used in the examples in this chapter.
  • Enforce through checks and balances in the batch files that everyone is using the published project build environment.

Recommendation for Versioning

What I recommend is to read and re-read this chapter to make sure you fully understand everything in it and to grasp the importance of reliable versioning. Here is a short list of what you need to do:

  • Use a four-part number separated by periods for your file version string.
  • Increment your build number before starting each build.
  • Avoid the use of dates in the build number.
  • Use your build number for the label in sources you just built.
  • Don’t try to include product marketing versions in your file version string.
  • For .NET programmers, don’t link assembly versioning to file versioning.
  • During your setup program, do the following:
    • Check for the OS that you are installing on.
    • Avoid copying anything to the system directory.
    • Copy all components to the same directory as the executable.
    • Avoid installing older components over newer ones.
    • Make a copy of any component you overwrite.
    • Use a self-extracting executable to update.

Recommendation for Build Security

With all the talk about security on the Internet and in the applications that are out there, we must not forget about keeping company “jewels” safe. Here are some recommendations that were covered in this chapter:

  • At a minimum, use the four-layer approach talked about in detail in this chapter:
    • Physical security— Doors, locks, cameras, and so on.
    • Tracking source changes— The build process.
    • Binary/release bits assurance— The tools process.
    • IT infrastructure— Company-wide policy and security.
  • Consider the .NET platform as a means of security.
  • Look into software restriction policies that are in Microsoft Windows XP and Windows Server 2003.
  • Start worrying about security before a breach occurs.

Recommendation for Building Managed Code

You will find that building projects for the .NET Framework is a bit different than the classic “unmanaged code builds” that have been around before Web services were ever dreamed up. I went over the parts of building .NET code that tend to trip people in this chapter; the following is a quick list of recommendations:

  • If you build managed code, learn the basic terms of the .NET Framework and the compilation process explained in this chapter.
  • Use delayed signing when developing your project to avoid having to sign the assemblies in conjunction with your daily build.
  • Understand the risk of exposing your developer’s machine to external attacks because of the skip verification list that is created when delaying signing.
  • Decide what is the most practical way of setting up your solution files for your .NET projects. Then enforce whatever policy you come up with through your CBT.

Recommendation for International Builds

Here is what is done at most of the bigger groups at Microsoft and is thus our preferred way of internationalizing our products.

  • Write single binary code as the first step toward truly world-ready products.
  • Implementing a multilingual user interface that allows users to switch between all supported languages is the next logical step.
  • Write Unicode-aware code and create satellite DLLs for your language resources to make these goals much easier to achieve.

Recommendation for Build Verification Tests and Smoke Tests

Some of the general points of the chapter are:

  • Run Visual File Information and VerCheck on each build.
  • Establish a quality bar that the build will be measured against
  • Let the test team own the BVTs, but let the build team run them.
  • Automate BVTs and smoke tests.
  • Track BVT results on a public intranet page.
  • Know the difference between BVTs and smoke tests.
  • Always have the testers or developers run the smoke tests, not the build team.

Recommendation for Building Setup

To improve your setup reliability the following should be done:

  • Decide which setup tool you will use: Wise, InstallShield, WiX, or another brand.
  • Track all files in your product in a spreadsheet or, better yet, a database. If you are using WiX, the files are listed in the .wxs file.
  • Build setup every day, and practice deploying your product to test machines every day. Do not release the build until setup has been created successfully.
  • Start pushing the setup responsibility back to the developers who own the modules.

Recommendation for Ship It!

The following list should be done as the final steps to shipping a great product:

  • Define what and when shipping is for your group. Follow Jim McCarthy’s Rule 21.
  • Start restructuring source trees before you ship, not after.
  • Establish a standard release process for your group.
  • Release a new build process after you release.
  • Add the shipping process time to the product schedule.

Recommendation for Customer Service and Support

From reading this chapter you should understand why you need to:

  • Create and invest in a strong support organization.
  • Make sure your support group has good paths back to the developers but are not intrusive to them doing their work writing code.
  • Outline specific escalation paths in support that give useful feedback to the product group.
  • Involve your support group as early as possible in the WAR meetings to discuss impacts.

Recommendation for Managing Hotfixes and Service Packs

A lot in this chapter was specific to VSS, but I think when you read this chapter you can draw parallels to the source code control tool you use and just copy the basic architect. These recommendations can be followed with any source code control tool but is more specific to VSS.

  • Use sharing to reuse common code modules.
  • Use labeling to isolate and mark different builds.
  • Use share and pin with branching to create new minor releases.
  • Use cloning to create new major releases.
  • Remember: Sharing is the first step of branching.

Recommendation for Suggestions to Change Your Corporate or Group Culture

  • Follow the seven suggestions to change or create a successful culture:
    • Involve as high a level of management as you can when rolling out new processes or tools. In fact, have the executive send the e-mail on the new announcement.
    • Hire a consulting firm to come in and perform an analysis.
    • Match company values to what you are trying to accomplish.
    • Do the math.
    • Not worrying about getting fired gives you incredible power.
    • Never take no from someone who does not have the power to say yes.
    • Publish policies, processes, and tools on the intranet!
  • If you can’t get 100 percent behind what you are doing, you should find something else to do or somewhere else to do it.

Recommendation for Future Build Tools from Microsoft

Looking into a crystal ball that predicts the future, you should see:

  • Adopt MSBuild as soon as possible.
  • Start researching VSTS and see if there are tools you can implement in your current build process and future processes.

 

 

 

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

Best Practices in Software Configuration Management – SCM Best Practices Guide

by scmgalaxy KPractice of Software Configuration ManagementLeave a Comment on 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 : / / / / / / / / / / / / / / / / / / / / / / / / / /

What Is Software Configuration Management, its importance & how to implement it?

by scmgalaxy KPractice of Software Configuration ManagementLeave a Comment on What Is Software Configuration Management, its importance & how to implement it?

software-configuration-management

Software engineers usually find coding to be the most satisfying aspect of their job. This is easy to understand because programming is a challenging, creative activity requiring extensive technical skills. It can mean getting to “play” with state-of-the-art tools, and it provides almost instant gratification in the form of immediate feedback. Programming is the development task that most readily comes to mind when the profession of software engineering is mentioned.
That said, seasoned engineers and project managers realize that programmers are part of a larger team. All of the integral tasks, such as quality assurance and verification and validation, are behind-the-scenes activities necessary to turn standalone software into a useful and usable commodity. Software configuration management (SCM) falls into this category—it can’t achieve star status, like the latest “killer app,” but it is essential to project success. The smart software project manager highly values the individuals and tools that provide this service.
This chapter will answer the following questions about software configuration management.

What Is Software Configuration Management?
Software configuration management (SCM) is the organization of the components of a software system so that they fit together in a working order, never out of synch with each other. Those who have studied the best way to manage the configuration of software parts have more elegant responses.
Roger Pressman says that SCM is a “set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.”>
We think that Pressman’s description is a better description because we often view SCM as meaning software change management.
Wayne Babich describes SCM as “the art of identifying, organizing, and controlling modifications to the software being built by a programming team. It maximizes productivity by minimizing mistakes.”>
The Software Engineering Institute says that it is necessary to establish and maintain the integrity of the products of the software project throughout the software life cycle. Activities necessary to accomplish this include identifying configuration items/units, systematically controlling changes, and maintaining the integrity and the traceability of the configuration throughout the software life cycle.
Military standards view configuration as the functional and/or physical characteristics of hardware/software as set forth in technical documentation and archives in a product. In identifying the items that need to be configured, we must remember that all project artifacts are candidates—documents, graphical models, prototypes, code, and any internal or external deliverable that can undergo change. In SW PM terminology, a configuration item might be a proposal/estimate or bid, project plan, risk management plan, quality assurance plan, CM plan itself, test plan, system requirements specification, system design document, review metric, code, test result, tool (editors, compilers, CASE), and so on. There are basic objects and aggregate objects to be configured. The number of relationships among them reflects the complexity of the configuration task.

Why Is SCM Important?
Software project managers pay attention to the planning and execution of configuration management, an integral task, because it facilitates the ability to communicate status of documents and code as well as changes that have been made to them. High-quality released software has been tested and used, making it a reusable asset and saving development costs. Reused components aren’t free, though—they require integration into new products, a difficult task without knowing exactly what they are and where they are.
CM enhances the ability to provide maintenance support necessary once the software is deployed. If software didn’t change, maintenance wouldn’t exist. Of course, changes do occur. The National Institute of Standards and Technology (NIST) says that software will be changed to adapt, perfect, or correct it. Pressman points out that new business, new customer needs, reorganizations, and budgetary or scheduling constraints may lead to software revision.
CM works for the project and the organization in other ways as well. It helps to eliminate confusion, chaos, double maintenance, the shared data problem, and the simultaneous update problem, to name but a few issues to be discussed in this chapter.

Who Is Involved in SCM?
Virtually everyone on a software project is affected by SCM. From the framers of the project plan to the final tester, we rely on it to tell us how to find the object with the latest changes. During development, when iterations are informal and frequent, little needs to be known about a change except what it is, who did it, and where it is. In deployment and baselining, changes must be prioritized, and the impact of a change upon all customers must be considered. A change control board (CCB) is the governing body for modifications after implementation.

How Can Software Configuration Be Implemented in Your Organization?
We used to say, “Make a plan and stick with it—never waffle,” and “Requirements must be frozen—how else will we know what to code?” Now, we say, “Plans are living documents—they will be in a continual state of change as project knowledge increases.” We now know that requirements are never frozen—they merge, morph, and evolve and become expanded, enhanced, and extended. As long as artifacts of software development can undergo change, we will need some method of managing the change.
Because SCM is such a key tool in improving the quality of delivered products, understanding it and how to implement it in your organization and on your projects is a critical success factor. This chapter will review SCM plan templates and provide you with a composite SCM plan template for use in any of your projects. We will cover the issues and basics for a sound software project CM system, including these:

  • SCM principles
  • The four basic requirements for an SCM system
  • Planning and organizing for SCM
  • SCM tools
  • Benefits of SCM
  • Path to SCM implementation

 

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

5 Keys to Automating Configuration Management for Application Infrastructure

by scmgalaxy KPractice of Software Configuration ManagementLeave a Comment on 5 Keys to Automating Configuration Management for Application Infrastructure

automating-configuration-management-for-application-infrastructure

5 Keys to Automating Configuration Management for Application Infrastructure

One of the trends being discussed in business, among vendors and in the analyst community is the importance of automating the functions performed by IT. Growing demands by the business, tight budgets and compliance pressures together accentuate the need for IT to be more agile, efficient and responsive to business stakeholders.

Naturally, vendors rush into this environment, each touting the unique benefits of its solution set and the urgency to move forward immediately.  A key area targeted for IT automation is the area of ‘configuration management.’  As it relates to automating day to day IT functions, configuration management can mean many different things: patch management, server and network management or others.

One of the newer targets for configuration management techniques is the application layer itself.  Think about that great stack of software that comprises a contemporary J2EE application—application server, web server, database, middleware and so on—typically from different vendors.  But they all adhere to industry standards, right?  So they all must plug and play together nicely, right? Not really.

In fact to make the entire stack work effectively, there are many individual configuration files, each one with a long list of their own parameters, which need to be edited, tuned and controlled.  And because the set of software is so complex, each element is managed by its own specialist in isolation without much knowledge of the other pieces of the puzzle.

The combination of many software assets, configured manually without much knowledge of dependencies leads to predictable results.  Someone makes a change in one area while stability and performance problems show up elsewhere.  Once the problem crops up, a team of IT specialists will take hours, maybe days to track down the problem and provide the solution.  Analyst firms like Enterprise Management Associates and Forrester Research agree problems in the configuration of the application infrastructure are now one of the leading causes of downtime.

Some vendors and businesses are now focused on a comprehensive approach to tackling this problem. The five building blocks required are easy enough to understand:

  1. Discovery and mapping—What application element and software assets do I have in my environment? How are they configured, item by item?
  1. Change monitoring—Inform management not only about the applications that have changed, but tell them how they have changed.

 

  1. Release Management—Sometimes called ‘provisioning,’ this relates to the ability to model configuration changes to the application infrastructure and then deploy those changes consistently across all phases of the application life-cycle.
  1. Auditing and Reporting—Show the business that IT supports corporate governance initiatives, not only at the server and network level, but also at the critically important application layer.

 

  1. Integration with the IT environment—Insure that the tools for configuration management of the application infrastructure work seamlessly with your problem management system or your configuration management database.

1.‘Discovery’ is usually where these solutions should start—as long as they do not end there!  In order to provide the IT team with a solution to managing the thousands of configuration settings in a J2EE application stack, you need to have a repository of the environment itself, a working model that reflects your application infrastructure.  With this repository of data in place, IT can then begin to comprehend how the various elements on the application layer are actually

2.‘Change Monitoring’ represents a critical component of a configuration management solution for application infrastructure.  With so many servers, instances and individual parameters, the number of configuration items quickly runs to the thousands per application.

Change monitoring must identify not only that a component changed, it must also identify exactly where the change was made and on which server(s).  Right now, IT specialists comb through text files trying to figure this out when there’s an application outage or when the application can’t make the transition out of the lab and into production. At mValent we call this “Hack and Hope”– they hack into text files, make a change and hope that it resolves the problem.  Automation tools instead can be used not only to find the change, but to find only relevant changes, ignoring unimportant differences.

Another key component of change monitoring to be addressed would be the notion of versioning and roll-back.  This is a well understood capability that exists in source code control systems and was applied by Documentum among others to the content management problem.  Now, we should focus on providing versioning and roll-back to the thousands of configuration settings which comprise a J2EE application stack.  Rather than have IT scramble to figure out what has changed when there’s an outage, let’s just re-instate a known working version of all of the configuration settings.  Then, IT can take the analysis and resolution off-line without the pressure to restore service immediately.

3. ‘Release Management’ is an important forward-looking area of a configuration management solution for application infrastructure. Right now, IT teams use a mixture of scripts and manual methods to deploy changes to application infrastructure settings. New solutions look to apply true automation to this process, insuring that configuration changes are modeled, evaluated and approved prior to deployment. Release management also validates that the process applies changes correctly. This also offers automatic deployment of changes to configuration settings and provides ‘out of the box’ templates for deploying new versions of an application server or a complete J2EE application stack.

These tasks currently take days to achieve and are error-prone.  Applying automation reduces cost and time while advancing quality.

4. ‘Audit and Reporting’ in a configuration management solution for application infrastructure refers to a capability report on the application infrastructure at a detailed level.  This would include reporting on change activity—which applications are driving the most change and causing IT execs the most headaches with SLAs.  Currently, this information exists at the server and network level, but less commonly for the applications themselves where change and upheaval is more likely.

Audit and Reporting also measures how your application infrastructure complies with recommendations, standards or your best practices for how the infrastructure should be configured.  Which assets are in compliance? Which are out of compliance?

Solutions should also measure change activity. Who made the change, Why, When, and so on.  And, it would be appropriate to measure whether changes were made according to your change process or were made outside that process.

5. ‘Integration with your IT environment’ in a configuration management solution for application infrastructure refers to the ability of the solution to fit with the other elements in the IT ecosystem, like your problem and incident management system, your Configuration Management Data Base (CMDB), a source code management system or your corporate LDAP directory.

Ideally the solution will integrate directly with these items and create a ‘closed loop’ environment for managing change to the application infrastructure.  As an example, when a ticket is opened requesting a change to the configuration setting for the web server, the solution should automate the actual change process, include the ticket number in the reason for change and report back to the incident system so that the ticket can be closed.

This eliminates yet another manual process and opportunity for error in IT management.

Benefits & Summary.  The major benefits of a configuration management solution for application infrastructure relate to reducing complexity and promoting compliance for IT.  By transforming today’s manual, error-prone tasks into a sequence of automated processes, your IT team will see benefits in:

·  Improving the productivity of your IT Infrastructure Team, by upwards of 50% and enabling them to spend more time on new initiatives rather than fire-fighting

·  Accelerating time-to-value for applications by 25%

·  Improving the quality and uptime of your applications by reducing the key elements that cause most of today’s outages

·  Providing comprehensive best practices and compliance reports to management and stakeholders.

With today’s IT struggling to meet increasing demands without headcount increases, a configuration management solution for application infrastructure offers important sources of value. configured.  More important, IT can begin to understand the dependencies between, say, how the data base is configured and its impact on the application server.  Thus, application configuration problems can be averted before they arise.

 Source: http://www.cmcrossroads.com

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