Next Generation Software Configuration Management with Subversion

The post Next Generation Software Configuration Management with Subversion appeared first on scmGalaxy.

Training Duration – 30 Days (90 mins each day)

Mode – Online (Webex | Skype | Gotomeeting)

Email –

Mode of Payment – Online Bank Transfer (Send us an email to info@scmgalaxy.com with the confirmed payment receipt for acknowledgement)

Registration is based on First Come basis and only confirmed registration would be considered.

Course Materials – Would be shared everyday end of the session every day

Lab – 70% of the training consist of lab.

Demo Class –  ScmGlaxy team does not believe in demo class concept as this is very difficult to evaluate any training/trainer very first day in 90 mins. Still, if you want to experience our training before enrollment, we may add you in any on-going live class based on your special request. If you want to know more about us – Click here

Refund – If you are reaching to us that means you have a genuine need of this training, but if you feel that the training does not fit to your expectation level, you may cancel your training within first three days of class and 100% refund will be processed.

What if you miss the scheduled class? – If you miss the scheduled class, you can be a part of other ongoing batches any time in future free of cost.

scmGalaxy Advantage – If you enroll for our courses, you can attend for our training any number of times of that specific course free of cost.

Tools Covered as Part of this Training – Jenkins, Git, SVN, Ant, Maven, MSBuild, Chef Fundamental, RPM, Shell Scripting and Linux

Course Outline :

Concept / Process / Principals / Overview

• Software Configuration Management overview
• Elements of Software Configuration Management
• Introduction of Version management / Source Code Management
• Overview of Build management
• Overview of Packaging management
• Overview of Release and Deployment management

Source Code Management Tools

• Git – Source Code Management
• SVN – Source Code Management – Fundamental only

Build Management Tools

• Apache Ant – A java based build Tool
• Apache Maven – A java based build tool
• Msbuild – A dot net based build tool – Fundamental only
• Jenkins – A continuous integration tool

Application Packaging Management Tools

• RPM – A linux based application packaging tool

Deployment Management / Configuration management – Fundamental only

• Chef – A configuration management tool

Application server – Fundamental only

• Jboss – An open source application server

Operating System

• Windows – A Microsoft operating system
• Linux – An open source operating system

Scripting

• Shell Scripting (Bash)

CI/CD Concept and Implementation

• Concept of Continuous Integration
• Concept of Continuous Deployment
• Concept of Continuous Delivery
• CI/CD Implementation

The post Build and Release Training online appeared first on scmGalaxy.

1…… General Assessment Questions. 2

1.1     Questions to analyze the development process description.. 2

1.2     Questions to characterize the project application.. 2

1.3     Questions to identify the supporting tools. 2

2…… Assessment on Configuration and Change Management   2

2.1     Project/Development Managers. 2

2.2     Developers. 3

2.3     Testers. 3

2.4     Configuration Manager. 3

3…… Assessment on Build and Release Management.. 3

3.1     Build Engineer. 3

3.2     Release Engineer. 4

1           General Assessment Questions

1.1      Questions to analyze the development process description

Which of the following do you get from your existing process?

·         Examples

·         Guidelines

·         Artifact templates

·         Activity descriptions

·         Artifact descriptions

1.2      Questions to characterize the project application

• What is the size of each project (duration, persons, person years,  LOC)

·         What type (maintenance / enhancement / new development / prototype /

§  feasibility)

• What type of development model is being used?
• Are we using any process models like UCM, RUP or any other?
• Any industry/domain specific standards (like CMMI, ITIL etc.) to be followed?

1.3      Questions to identify the supporting tools

·         What are the tools that you currently use in your work?

·         How is the integration among the above tools?

·         Are we using the tool features the way they are designed or intended?

2           Assessment on Configuration and Change Management

2.1         Project/Development Managers

·         How do you maintain all the artifacts together and version them?

·         Where are the people working on the project located?

·         What’s the difference between Developer CM and Release CM?

·         How do you assess, and track the impact of a proposed change?

·         How do you manage system integration of modules developed by individual developers?

·         How many product versions are you supporting at this moment?

·         Who is the designated Configuration Manager?

2.2         Developers

·         How do you baseline project artifacts?

·         Can you build your system reliably and repeatedly?

·         Explain your labeling scheme?

·         Can you show me what versions went into a certain release?

·         What does the version tree for this file look like?

·         How many product versions are you supporting at the moment?

·         What is the version control tool being used? Is it user friendly?

·         What is the bug tracking/change management tool being used? Is it user friendly?

2.3         Testers

·         Do you know what files/documents should be delivered?

·         How do you assess, and track the impact of a proposed change?

·         Can you show me what artifact versions went into a certain release?

·         How comfortable are you working with Bug/Change management tool?

2.4         Configuration Manager

·         Do you know what files/documents should be delivered?

·         How do you track who changed what, when, where, and why?

·         How long does a build or release take?

·         Is there a Configuration Management Plan document?

·         Is there a tight integration between Version control tool and Bug/Change tracking tool?

·         How the parallel (if any) development is enabled? Any limitations with the current branching strategy?

·         Is this project development spanned across multiple sites? If so, what is your multi-site strategy?

3          Assessment on Build and Release Management

3.1         Build Engineer

• What is the build process adopted (automated/manual)?
• Are there nightly builds?
• Is there continuous integration?
• Are there smoke and sanity tests at the end of the build?
• What is the build acceptance criterion (BAT)?
• What is the build duration? Is it optimal?
• How are pre-conditions to the build verified?
• Are there any build environment integrated automated unit test-cases?
• Is there any enforcement tool on coding standards?

• Is there any code coverage tool being used?
• Are the post build activities automated?
• Any additional practices (like checksum generation, signing the build artifacts) in place as part of the build?
• Are there any scripting technologies used in automating build process?
• Is Labeling strategy well-defined?
• If any third party tool is being used for packaging, is that package creation process automated?

3.2         Release Engineer

• How many major, minor releases a year per project?
• How many customers per release per project?
• How do you deliver the releases to the customers? – Is it physical media distribution or Push/Pull mechanism from web or any other process?
• Is the distribution CD/DVD creation process automated?
• What is the size of the release deliverable?
• What are the contents of a release?
• How is the release bundle tested?
• How many platforms are certified? How different are the release packages?
• Is there any release check-list for cross-check?
• Is any part of the release process automated?
• Is there a need for i18n? If yes, is the i18n release handled separately?
• In case of installers, is there installer testing? Is it automated?
• Is the release schedule well-planned?
• Are you delivering patches in well constructed and cost effective way?
• Is there any release audit process in place?
• How are you tracking your releases?
• Is there any legal compliance in place while shipping the release to the customers?

The post Questionnaire: Access your SCM Process in Project appeared first on scmGalaxy.

1. Identification—Each software part is labeled so that it can be identified. Furthermore, there will be different versions of the software parts as they evolve over time, so a version or revision number will be associated with the part. The key is to be able to identify any and all artifacts that compose a released configuration item. Think of this as a bill of materials for all the components in your automobile. When the manufacturer realizes that there has been a problem with parking brakes purchased from a subcontractor, it needs to know all the automobile models using that version of the parking brake. It is the same with software. If we are building a multimedia system that has audio MPEG3 drivers for Windows 98, Windows 2000, Windows CE, Linux, and FreeBSD operating systems, how do we find out which releases are impacted when we find an error in the Linux product? You must go back to your SCM system to identify all the common components in all operating system releases that are impacted.
2. Control—In the context of configuration management, “control” means that proposed changes to a CI are reviewed and, if approved, incorporated into the software configuration. The goal is to make informed decisions and to acknowledge the repercussions associated with a change to the system. These changes may impact budgets, schedules, and associated changes to other components. If a problem is reported in a released product, software engineers must act quickly to evaluate repercussions—a “fix” for one client’s version of the product may be dangerous to another. The control inherent in an SCM system shows each version in which the flawed component appears.
3. Auditing—Auditing an SCM system means that approved requested changes have indeed been implemented. The audits allow managers to determine whether software evolution is proceeding both logically and in conformance with requirements for the software. The SCM system should document changes, versions, and release information for all components of each configuration item. When such documentation is in place, auditing becomes a straightforward analysis task.
4. Status accounting—Reports and documentation produced by the status accounting function are the auditable entries. All approved parts of a software configuration must be accounted for, and the software parts list must reflect the transition from part CIn to CIn+1. This accounting provides the historic information to determine both what happened and when on the software project. Status accounting enables the auditing requirement of the SCM. As a project manager, the status accounting holds a wealth of information on the amount of effort required throughout the life cycle of the product in its development and maintenance. This is critical to the software project manager in making estimates for new systems based on historic information. The SCM can be used as one of the key components of the project managers’ metrics system.

The post The Four Basic Requirements for an SCM appeared first on scmGalaxy.

Basic selection criteria includes the following:

• Multiuser support—Tools are to be used concurrently by several users. They have to store all acquired information in a central, shared repository, and the SCM tool has to allow controlled parallel work on the different project documents.
• Intuitive GUI—Because the tools will be used throughout the project and not only by developers, an intuitive, easy-to-use graphical user interface is considered very important.
• Conformity to the organization’s development environment—The organization must define up front the hardware and software development platforms used. For example, the project may work on a heterogeneous network of Unix-based workstations (mainly Sun Sparc stations) and PCs. The workstations may be used for some part of the development and as a file server and communication server. The PCs may be using MS Windows 2000 NT. PCs and workstations may be interconnected using the NFS protocol (especially Sun PC-NFSpro on the PCs). The tool has to be able to store its shared repositories on a workstation and has to allow PC clients as well as workstation clients supporting the operating systems and protocols.
• Scalability—The tool should work equally well for smaller projects as for larger ones.
• Flexibility in integrating other software development tools—The tool must allow the integration of all the other development tools to provide a highly homogeneous environment. Especially the tools for design, implementation, and testing will have to co-operate on the common SCM repository.
• Ease of setup—The SCM tool should allow an easy installation and setup, and should be able to run nearly “out of the box.” It should contain predefined, immediately usable models describing the types of items, the life cycle, and the roles of the different users. The importance of existing projects and their directory structures should be made as easy as possible.
• Modifiable models—Though a working set of models should be predefined, each of these should be modifiable and extensible. This is especially important because project managers and developers want to adapt these models to the software development process as defined for the company. Role models must be adapted to the roles assigned to the different employees on the project. Object-type models must be extensible to reflect different types of objects used in the environment and especially with respect to nondevelopment objects.
• Process management—Process management comprises efficient support of object life cycles and object promotion, together with a flexible and extensible approach to life cycle models. Based on a concept of object types, it should be possible to attach different life cycles to different types of objects.
• Extensive support for the development phase—During development when checkout and update of objects is frequent, the tool should aid a developer in determining the set of objects that need an update or renewed check-in. Although this requirement seems to be trivial at first, the latest version of the tool you plan to use must be evaluated with emphasis on the environment prior to the first build. These do a good job in change management once the first release has been produced.
• Management of nondevelopment objects—SCM tools must manage all artifacts of the project, not just code. These will mainly be documents and their versions and releases. The tool must be able to support that.
• Permission management—Everyone should not have access to make changes to different pieces of the software. In many situations, check-in and checkout only will not prevent integration from being broken by multiple people modifying code for their own designs and interfaces.

Many configuration management tools in the market promise to fulfill more or less all of the requirements. Chapter 24, “Use of Tools,” presented a general model for the selection of tools to support software development and project management. The keys to any tool selection are to know your project’s tool requirements, to understand how tools relate to the project’s success factors, and to do a current market search for tools. The following is an example of using that tool selection method for an SCM tool. This is simply an example, and it must be updated with individual key project success factors, tool requirements, and the tools available in the market based on the project’s schedule requirements.

The post The minimum features for SCM tools appeared first on scmGalaxy.

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.

The post Versioning in Software Configuration Management | SCM Versioning Guide appeared first on scmGalaxy.

SCM Process and smartBuild

The post SCM Process and smartBuild Overview, What is SCM Process and smartBuild? appeared first on scmGalaxy.

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.

The post Software Configuration Management in Pakistan | SCM Practices in Pakistan appeared first on scmGalaxy.

scmGalaxy is a community initiatives based on Software configuration management that helps community members to optimize their software development process, Software Development Life Cycle optimization, Agile Methodologies and improve productivity across all aspects of Java development, including Build Scripts, Testing, Issue Tracking, Continuous Integration, Code Quality and more!

scmGalaxy is a community initiatives based on Software configuration management that helps community members to optimize their software development process, Software Development Life Cycle optimization, Agile Methodologies and improve productivity across all aspects of Java development, including Build Scripts, Testing, Issue Tracking, Continuous Integration, Code Quality and more. scmGalaxy group that helps organisations optimize their software development process. We provide consulting, training and mentoring services in Agile Development Practices such as Version Management, Continuous Integration, Build Management, Test-Driven Development, Acceptance-Test Driven Development, Build Automation, Code Quality Practices and Automated Testing.

We provide job oriented training in the area of Configuration management, Build and Release Engineering. Candidates with engineering or software background and looking to either start or change their career to Build and Release Engineering, would benefit most from this training. Instructor-led training course offered in India, Bangalore, Delhi, Pune, Mumbai and Hydrabad. Instructor is an expert in Software configuration management, Build and release engineering with more than 15 years industry experience in india.The Goal of the course make the training attendants equip with all the concepts of build and release engineering.

Course Objectives
To bring your team up to speed with agile development, We can also run the from Continuous Integration to Continuous Delivery with autoamted course within your premises.

Course Schedule
This course is an intensive 1-day & 2-day workshop with a mixture of teaching and lab exercises. Currently, this course is offered exclusively as an on-site course. Please contact us for more details.

Audience
This is a hands-on, practical course designed to teach specialised skills for real-world development situations. It is thus primarily aimed at a SCM Engineer, Build/Release Engineer and developer audience.

Approach
The course is modular and flexible – depending on specific student needs and requests. Through our trainings, you benefit from the wide experience and architectural expertise of our team. We bring that experience to you in an highly interactive, intensely hands-on setting.

Assumptions
We assume participants have a reasonable understanding of Development in any language as well as a basic understanding of the Software Development Life Cycle.

Lab Work
All our courses are above all practical in nature. We believe that the best way to learn is by doing. So the course contains approximately 80% lab work.

Learning Resources
Each registrant will receive a copy of the student notes and lab solutions, a certificate of completion, and a CD containing all the tools covered in the course and CD containing all the tools covered in the course.

Contact Us
This course is provided on-site, and can be tailored to your particular requirements. If you would like our trainings delivered at your premises, or for any additional information please contact us. Please email us at info@scmGalaxy.com

Authors and Contributors

Rajesh Kumar, India (Bangalore), over 8 years of extensive experience in SCM domain having depth knowledge of Configuration Management, Build Management, Packaging, Release Management and Application Maintenance. Expertise in Wide range of CM tools (Perforce, MKS, CVS and SVN(Subversion) and VSS), packaging tools (Wise Studio/InstallAnywhere) and Build Management (Ant, CruiseControl, Anthillpro, Maven, Bamboo, Hudson & OpenMake) and Quality related tools like (Sonar, PMD, CheckStyle, Clover and FindBugs). He writes blogs on http://www.scmGalaxy.com
His primary areas of involvement are in object-oriented development, agile methods, enterprise application architecture, Workflow Management System and Automated Build and Release, Continuous Integration, Build Automation, Test-Driven Development and Code Quality, using open source tools such as Maven, Hudson, and Nexus. Environment.

Praveen Marakkoor, Praveen currently working as Sr SCM Engineer for Blue Shield of California San Francisco,CA USA previously he held Development and SCM positions at Kyocera Wireless,24 Hour Fitness, Experience, Macys, Cisco and Intuit. He has extensive experience in Software Configuration Management and Release Engineering and its tools like Maven,Ant,Perforce,maven, SVN, CVS, Clearcase, PVCS, git, Hudson, Bamboo, perl, shell scripting on heterogeneous environments along with QA Engineering.
Praveen holds a Bachelors Degree in Computer Science and Engineering from Visweswaraya Technological University Belgaum, Karnataka India. Highly detail oriented leadership skilled and a team player. He writes blogs on http://www.scmGalaxy.com

Tushar Patil, Currently working with S1 Services, Pune as Sr SCM Engineer.Having around 8 years extensive experience in Configuration Management and Release Engineering. Expertise in tools like SVN, Ant, Maven, Izpack, Perl, Clover, Shell Scripting, Hudson, Bamboo. Having very good experience in OS installations on Vmware ESX servers(AIX,Red Hat,Solaris) and installtion/configuration/troubleshooting of various softwares like WebSphere ND, Jboss, DB2, Oracle on AIX,Solairs and RedHat operating systems.

Brajesh Kumar Rai, Over 7 years of extensive experience in Configuration Management, Build Management, Release Management and Application Maintenance. Expertise in Wide range of CM tools (Perforce, ClearCase, CVS and SVN), packaging tools (InstallAnywhere) and Build Management (Ant, Maven, Make, CruiseControl, Anthillpro, Electric Cloud, Buildbot) multisite projects. Apart from always I am very adventures ,love any kind of crazy adventure, expert in Rock Climbing and rafting, Loves music gazals preferred. He writes blogs on http://www.scmGalaxy.com

Michael Feighner, USA(San Francisco) Expertise in C/C + +, CMMI, change management, clearcase, clearquest, configuration/data management, database admin, delivery, doors, e-commerce, FORTRAN, GUI, meeting facilitation, MS Excel, MS Word, MS PowerPoint, OOD, perl scripting, process engineering, programming, quality control, requirements, scheduling, shell scripting, sw development, sw installation, sw testing, sql, unix, visual basic, visual studio, vxworks, web site production.

Praveen Thakur, India (Pune) Expertise in InstallShield and Application Packaging Domain. He writes blog on http://www.scmGalaxy.com

The post Know About scmGalaxy – Introduction appeared first on scmGalaxy.

Power Point PPT: Introduction To Software Configuration Management

The post Power Point PPT: Introduction To Software Configuration Management appeared first on scmGalaxy.

Power Point PPT: Scm With Mks Integrity

The post Power Point PPT: Scm With Mks Integrity appeared first on scmGalaxy.

Power Point PPT: Software Configuration Management And CVS

The post Power Point PPT: Software Configuration Management And CVS appeared first on scmGalaxy.

Power Point PPT: Why Software Configuration Management

The post Power Point PPT: Why Software Configuration Management – Prsesentation appeared first on scmGalaxy.

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.

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

The post Best Practices in Software Configuration Management – SCM Best Practices Guide appeared first on scmGalaxy.

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

The post What Is Software Configuration Management, its importance & how to implement it? appeared first on scmGalaxy.