Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now

Skill Sets of SCM, Build and Release Engineers

Build / WorkFlow Mgmt Tools

  • AnthillPro
  • Apache Continuum
  • Bamboo
  • CruiseControl
  • Hudson
  • LuntBuild
  • OpenMake Meister
  • TeamCity
  • Team Foundation Server
  • Electric Cloud
  • Others

SCM Tools

  • AccuRev
  • ClearCase
  • CA Harvest
  • CVS
  • Dimensions
  • Git
  • MKS Source Integrity
  • Mercurial
  • Perforce
  • PVCS
  • StarTeam
  • Subversion
  • Synergy
  • Team Foundation Server
  • Vault
  • ViewVC
  • VSS
  • Others

Scripting

  • Ant
  • Groovy
  • Make
  • Maven
  • MSBuild
  • NAnt
  • Shell Scripts
  • Perl Scripts
  • Python Scripts
  • Visual Studio
  • Others

Release / Dep Tools

  • Cruise
  • Rational Team Concert
  • Manual
  • Others

Security

  • Active Directory
  • Kerberos
  • LDAP
  • Single Sign-on
  • RSA SecurID
  • Others

Testing Tools

  • Agitar
  • CppUnit
  • HP Mercury Quality Center
  • HP Mercury QuickTest Pro
  • JUnit
  • MSTest
  • NUnit
  • Selenium
  • Silk Central Test Manager
  • TestNG
  • Others

Test Coverage

  • Clover
  • Cobertura
  • Emma
  • Others

Source-code Analysis

  • Checkstyle
  • CodeSonar
  • Coverity
  • FindBugs
  • Fortify
  • Klocwork
  • PMD
  • Sonar
  • Others

Issue Tracking Tools

  • Bugzilla
  • ClearQuest
  • HP Quality Center
  • JIRA
  • PVCS Tracker
  • Team Foundation Server
  • TeamTrack
  • VersionOne
  • Others

IDEs Integration

  1. Eclipse
  2. RAD
  3. Visual Studio
  4. Others

Virtualization

  1. VMWare Lab Manager
  2. Microsoft
  3. Amazon (Elastic Cloud)
  4. Others
Tagged : / / /

Questionnaire: Access your SCM Process in Project

TABLE OF CONTENTS

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?
Tagged : / / / /

Roles of CM Users and Views of CM

Roles of CM Users and Views of CM
Different views of CM emanate from the different roles and concerns of people in an organization.

A simple, typical, CM user scenario of an organization is described in order to present the various roles and the subsequent views of CM support. The scenario involves various people with different responsibilities: a project manager who is in charge of a software group, a configuration manager who is in charge of the CM procedures and policies, the programmers who are responsible for developing and maintaining the software product, the tester who validates the correctness of the product, the quality assurance (QA) manager who ensures the high quality of the product, and the customer who uses the product. Each role comes with its own goals and tasks. For the project manager, major goals are to ensure that the product is developed within a certain time frame and meets the customer’s  requirements. Hence, the manager monitors the progress of development and recognizes and reacts to problems. This is done by generating and analyzing reports about the status of the software system and by performing reviews on the system.

The goals of the configuration manager are to ensure that procedures and policies for creating,
changing, and testing of code are defined and followed, as well as to make information about the project accessible. To implement techniques for maintaining control over code changes, this manager introduces mechanisms for making official requests for changes, for evaluating changes (via a Change Control Board (CCB) that is responsible for approving changes to the software system), and for authorizing changes. The manager creates and disseminates task lists for the programmers and basically creates the project context. Also, the manager collects statistics about components in the software system, such as information determining which components in the system are problematic.

For the programmers, the goal is to work effectively in creating the product. This means programmers do not unnecessarily interfere with each other in the creation and testing of code and in the production of supporting documents. But, at the same time, they communicate and coordinate efficiently. They use tools that help build a consistent software product, and they communicate and coordinate by notifying one another about tasks required and tasks completed. Changes are propagated between each other’s work by merging those changes and resolving any conflicts. A history is kept of the evolution of all components in the product along with a log of what actually changed and reasons for those
changes. The programmers have their own work area for creating, changing, testing, and integrating code. At a certain point, the code is made into a baseline from which further development continues and from which parallel development for variants of other target machines emerges.
The tester’s goal is to make sure every component of the product is tested and found satis-factory. This involves testing a particular version of the product and keeping a record of which tests apply to which version of the product along with the results of the tests. Any errors are reported back to the appropriate people, tracked and fixes are put through regression testing.

The Quality Assurance (QA) manager’s goal is to ensure the high quality of the product. This means that certain procedures and policies must be fulfilled with the appropriate approval. Bugs must be fixed and fixes propagated to the appropriate variants of the product with the correct amount of testing applied to each variant. Customer complaints about the product must be followed up.

The customers use the product — most likely, different customers use different versions and variants of it. Customers follow certain procedures for requesting changes and for indicating bugs and improvements for the product.

As a result of the various roles, an organization ends up with several views of CM. These views range from corporate CM (CCM) and project CM (PCM) to developer CM (DCM) and application CM (ACM). The former two views treat CM as a management and control discipline emphasizing the process aspect of CM, while the latter two views treat CM as a developer support function emphasizing tool support for CM. CCM focuses on maintaining CM information for a product, whose data is the basis for strategic impact analysis and process improvement. PCM focuses on managing change to a product through formal control processes such as change authorization via CCBs and configuration managers guarding CM repositories. DCM focuses on supporting developers (programmers) performing actual changes, maintaining history of actual changes, and providing stability and consistency through system build and team support. ACM focuses on configuration of applications as they are deployed, addressing issues of installation management, as well as dynamic configuration and reconfiguration. Ideally, a CM system suited to the views should support all these goals, roles and tasks.

Reference: 
The State of Automated Configuration Management
A. Brown, S. Dart, P. Feiler, K. Wallnau

Tagged : / / / / /

Configuration Management

Hey everyone – we are having a discussion about getting started in CM – in the CM Crossroads forums http://bit.ly/awKvKA. Please feel free to respond here, in the forums or contact me directly at bob.aiello@ieee.org

Bob Aiello
Editor in Chief
CM Crossroads
http://www.linkedin.com/in/BobAiello

______________________________________________________________

Hi Rajesh – did you actually “test” the link, that I posted, before saying that it was “illegal”. It resolves just fine and it points to an active discussion on Getting Started in Configuration Management.

Hi bagaloreorbit – I DID SAY “Please feel free to respond here…” – didn’t I???? Gentlemen – I have been promoting Configuration Management in virtual communities for many many years. CM professionals are true corporate citizens who share their knowledge and expertise. Let’s model that corporate citizenship. Feel free to send me an email directly at Bob.Aiello@ieee.org or on skype: BobAiello.

 

  • Rajesh Kumar

    Rajesh Kumar 

    Hi Robert,

    the link which you have given for CM crossroads is false. I would request you to correct the link as soon as possible. its violating the community rules as you are providing false link.

    cm Crossroads link is:www.cmcrossroads.com

  • bangaloreorbit

    bangaloreorbit 

    This is Short url to cm-crosswords.

    Robert, I guess we can discuss here same topics instead of moving multiple platform 🙁

Tagged : / /

The Four Basic Requirements for an SCM

Identification, control, audit, and status accounting are the four basic requirements for a software configuration management system. These requirements must be satisfied regardless of the amount of automation within the SCM process. All four may be satisfied by an SCM tool, a tool set, or a combination of automated and manual procedures.

  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.
Tagged : / / / / / / /

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.

Tagged : / / /

Versioning in Software Configuration Management | SCM Versioning Guide

versioning-in-software-configuration-management

Versioning in Software Configuration Management?

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

Why Worry About Versioning?

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

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

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

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

File Versioning

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

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

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

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

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

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

Build Number

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

How Versioning Affects Setup

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Importance of Automation Tools in SCM

automation-tools-in-scm

Importance of Automation Tools in SCM
by John Ferguson Smart

Since the dawn of time, people have been using tools to make their life easier. Tools let you solve a problem at hand more quickly and more efficiently, so that you can spend your time doing more interesting things. The stone axe, for example, enabled your prehistoric hunter to cut up meat more efficiently, thus leaving the tribe with time to do much more satisfying activities such as grilling mammoth steaks and painting on cave walls.

Of course, not all tools are equal, and tools have a tendency to evolve. If you go down to your local hardware store nowadays, you can probably find something even better to chop up your firewood or to chop down a tree. In all things, it is important to find the tool that is most appropriate for the job at hand.

The software industry is no exception in this regard. There are thousands of tools out there, and there is a good chance that some of these can help you work more efficiently. If you use them well, they will enable you to work better and smarter, producing higher quality software, and avoiding too much overtime on late software projects. The hardest thing is knowing what tools exist, and how you can put them to good use.

That’s where this book can help. In a nutshell, this book is about software development tools that you can use to make your life easier. And, in particular, tools that can help you optimize your software development life cycle.

The Software Development Life Cycle (or SDLC) is basically the process you follow to produce working software. This naturally involves coding, but there is more to building an application than just cutting code.

You also need a build environment.

When I talk of a build environment, I am referring to everything that contributes to letting the developers get on with their job: coding. This can include things like a version control system (to store your source code) and an issue management system (to keep track of your bugs). It can also include integration, testing, and staging platforms, in which your application will be deployed at different stages. But the build environment also includes tools that make life easier for the developer. For example, build scripts that help you compile, package and deploy your application in a consistent and reproducible manner. Testing tools that make testing a less painful task, and therefore encourage developers to test their code. And much more.

Let’s look at a concrete example. My picture of an efficient, productive build environment goes something along the following lines.

You build your application using a finely tuned build script. Your build script is clean, portable, and maintainable. It runs on any machine, and a new developer can simply check the project out of the version control system and be up and running immediately. It just works.

You store your code in a central source code repository. Whenever you commit your code, a build server detects the change to the code base, and automatically runs a full suite of unit, integration, and functional tests. If any problems crop up, you (and the rest of the team) are immediately notified. You have learned from experience that committing small, regular changes makes the integration process go a whole lot smoother, and you organize your work accordingly.

You use an issue tracking system to keep tabs on features to implement, bugs to fix, or any other jobs that need doing. When you commit changes to your source code repository, you mention the issues that this change addresses in the commit message. This message is automatically recorded against these issue in the issue management system. Furthermore, if you say “Fixes #101,” the issue automatically will be closed.

Conversely, when you view an issue in the issue management system, you can also see not only the commit messages but also the exact modifications that were made in the source code. When you prepare a release, it is easy to compile a set of reliable release notes based on the issues that were reported as fixed in the issue tracking system since the last release.

Your team now writes unit tests as a matter of habit. It wasn’t easy to start with, but over time, coaching and peer programming have convinced everyone of the merits of test-driven development. Automatic test coverage tools help them ensure that their unit tests aren’t missing out on any important code. The extensive test suite, combined with the test coverage reports, gives them enough confidence to refactor their code as necessary. This, in turn, helps keep the code at a high level of reliability and flexibility.

Coding standards and best practices are actively encouraged. A battery of automatic code auditing tools checks for any violations of the agreed set of rules. These tools raise issues relating to coding standards as well as potential defects. They also note any code that is not sufficiently documented.

These statistics can be viewed at any time, but, each week, the code audit statistics are reviewed in a special team meeting. The developers can see how they are doing as a team, and how the statistics have changed since last week. This encourages the developers to incorporate coding standards and best practices into their daily work. Because collective code ownership is actively encouraged, and peer-programming is quite frequent, these statistics also helps to foster pride in the code they are writing.

Occasionally, some of the violations are reviewed in more detail during this meeting. This gives people the opportunity to discuss the relevence of such and such a rule in certain circumstances, or to learn about why, and how, this rule should be respected.

You can view up-to-date technical documentation about your project and your application at any time. This documentation is a combination of human-written high-level architecture and design guidelines, and low-level API documentation for your application, including graphical UML class diagrams and database schemas. The automatic code audits help to ensure that the code itself is adequately documented.

The cornerstone of this process is your Continuous Integration, or CI, server. This powerful tool binds the other tools into one coherent, efficient, process. It is this server that monitors your source code repository, and automatically builds and tests your application whenever a new set of changes are committed. The CI server also takes care of automatically running regular code audits and generating the project documentation. It automatically deploys your application to an integration server, for all to see and play around with at any time. It maintains a graphical dashboard, where team members and project sponsors can get a good idea of the general state of health of your appplication at a glance. And it keeps track of builds, making it easier to deploy a specific version into the test, staging, or production environments when the time comes.

None of the tools discussed in this book are the silver bullet that will miraculously solve all your team’s productivity issues. To yield its full benefits, any tool needs to be used properly. And the proper use of many of these tools can entail significant changes in the way you work. For example, to benefit from automated testing, developers must get into the habit of writing unit tests for their code. For a continous integration system to provide maximum benefits, they will need to learn to commit frequent, small changes to the version control system, and to organize their work accordingly. And, if you want to generate half-decent technical documentation automatically, you will need to make sure that your code is well-commented in the first place.

You may need to change the way people work, which is never easy. This can involve training, coaching, peer-programming, mentoring, championing, bribing, menacing, or some combination of the above. But, in the long run, it’s worth it.

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

SCM Process and smartBuild Overview, What is SCM Process and smartBuild?

scm-process-and-smartbuild

SCM Process and smartBuild

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

Software Configuration Management in Pakistan | SCM Practices in Pakistan

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

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

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

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

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

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

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