The potential of Ranchi as a future powerhouse of the country and emerging city for the IT Companies has been duly recognized in the recent surveys by “timesofindia”, with Ranchi receiving significant investments from various Software Development Companies after incentives offered by the government under its “Software Technology Park of India” (STPI) policy 2016.

As Information technology companies are one of the highest contributors to GDP growth and job creation, Ranchi also has witnessed a tremendous transformation into a dynamic city where currently 100 + Software Companies are operational. Surveys are also presuming that in the next two years IT companies in Ranchi will generate 10 thousand plus JOBS and Jharkhand will raise 30 thousand plus JOBS in the state for the Software developers.

But, the question is which IT companies are best in Ranchi for Software Developers JOBS or for any other purpose?

If you do search on Google for the best Software Development Companies in Ranchi you will find many Software Companies list on google results, but most of the time suggested results are those who have done better Serch Engine Optimizations.

If you are looking for the list of software development companies in Ranchi – this is the right listing to get the best results of top IT companies in Ranchi. These software companies are not ranked according to in position they have been randomly written.

1. Cotocus:- Cotocus Private Limited is a global product based software development company in Ranchi with track record of 6 years and extensive workforce of efficient employees working on the various porducts of the company. This is the only product based software development company currently functional in Ranchi and in Jharkhand where 50+ employees and 20+ Interns are working.

If you will go to their web page career section, every 6 months they use to hire new software developers in the company and also give opportunities of paid INTERNSHIP to the Computer science graduates or equivalent degrees like BCA, BSCIT, Diploma in Computer Science candidates.

• Rating:- 5/5
• www.Cotocus.com
• Job Apply @ Email – contact@cotocus.com

2. HolidayLandmark:- This company is situtated at Ranchi where 70+ employees are working and built this platform where you can discover the most amazing travel and events expereince around the world with the help of Holidaylandmark.com. This application is making it easy to connect and plan holidays in group or solo trip with all the needed assistance with incredible deals.

This place has a great work environment provides exceptional career opportunities for Software developers. Team size of 100 people and growing day by day and always look for various talents to hire them in the workforce to reach the goal “India’s best trip planning platform”

• Rating:- 4.5/5
• www.HolidayLandmark.com
• Job Apply @ Email – contact@holidaylandmark.com

3. Professnow:- Professnow team is working to resolve a big problem of the society. After pandemic there are two common questions arisen “How to regrow your Business after Covid-19 Pandemic hit?” and “How to go online and reach customers and clients after the Covid-19 pandemic hit?”.

Professnow team is working on a mission where they are trying to solve Professionals problems and the same time customers problems. If you will read their statement – you would totally get that “We are here to build the world’s best on-demand service experience and professionals community to empower all levels of service providers and professionals of our society to reach their potential customers without technology being a barrier for them where users can easily connect and book their service needs.”

As they are working on this huge mission, they also need a team of skillful IT engineers. They are also one of the best Software development companies in Ranchi always searching for the best talent in the local area to hire.

• Rating:- 4.8/5
• www.Professnow.com
• Job Apply @ Email – contact@professnow.com

4. DevOpsSchool:- DevOpsSchool is an ED-Tech next generation solution built to resolve IT Companies and Software professional’s skills up-gradation and digital transformation problems.

This company has developed a one-stop solution platform dedicated for Software professionals. Being a software company or software professional – if you need any skill up-gradation workshops or programs whether its online or offline for the group of employees or as an individual, you may use this platform to find the best trainers and top consulting firms at the best rates.

Managing such a huge application is not an easy task. Being a software developer if you are trying to find a job in Ranchi, you can apply here – If you get selected, you are going to learn a lot of things in a short span of time.

• Rating:- 4.9/5
• www.DevOpsSchool.com
• Job Apply @ Email – contact@devopsschool.com

5. Wizbrand:- Wizbrand is a Digital Marketing Company having a slogan of shaping Digital Era, developed and offer a powerful platform for all Digital marketing needs. Individuals and Organizations can preapare their digital marketing startegies and manage all their digital marketing projects, assets, tasks, resources and track their progress and stay organized with centralized workspace “WizBrand.com”.

This software company is functional for several years in Ranchi and having tremendous growth and they always use to publish their JOB requirements every quarter through various channels.

• Rating:- 4.4/5
• www.Wizbrand.com
• Job Apply @ Email – contact@wizbrand.com

6. Brightcode:- Brightcode functional since 2019 in Ranchi and relentlessly helping startups and enterprises to improve their business presence and workflow process with innovative software solutions.

• Ratings:- 4.3/5
• www.brightcodess.com

7. Ubiqueit:- Ubique is one of software company in Ranchi running last 5 yrs provides IT Services, software design and development as well as professional services and hardware deployment and maintenance to the flenties of vertics.

• Ratings:- 4.2/5
• www.ubiqueit.com

8. JIS:- Jharkhand IT Services(JIS) – operating in Ranchi since 2015. It provides Design and Development Solutions and as well as Domain and Hosting Services. They have very good track record and expertise in Android/iPhone mobile app Development.

• Ratings:- 4.4/5
• www.jharkhanditservices.com

9. Tripledots:- Tripledots running since 2020 a reputable software company in Ranchi having a good client base from diverse industries, including Healthcare, Tourism, Real Estate, Manufacturing, Hospitality, Online Media Houses, Banks, and more.

• Ratings:- 4.3/5
• www.tripledotss.com

10. Matrop:- Serving as IT company in Ranchi since 2012 MATROP has successfully designed, developed and implemented websites/Software’s/ERPs/Applications for many Government and private oranizations by providing custom packages focused on their busines need and goals.

• Ratings:- 4.6/5
• www.matrop.com

Did I just finish the list? Well, then let me tell you that many of the Ranchi readers might be feeling that other software development companies must be present in this list. So if this is the case or if I have missed any reputed IT company of Ranchi in the list then please don’t forget to write a comment with the complete address of the company.

The post List of software development company in Ranchi appeared first on scmGalaxy.

What is Blockchain Developer?

Blockchain developer skills are a combination of hard skills and soft skills from an abstract point of view. They can handle the entire life cycle of a blockchain application. This means that you will be responsible for the execution of the application as well as research.

Types of Blockchain Developers:

There are two types of Blockchain Developer.

• Blockchain software developer
• Core blockchain developer

They are both involved in blockchain development, but they have different responsibilities.

Blockchain Software Developer

Blokchain software developers to create applications based on Blokchain architectures and protocols. Their apps also run on the blockchain. You can compare them to web developers, who use the products of a web architect (protocol and design) to develop web applications.

Blockchain software developers create dapps or decentralized applications. They are responsible for the back-end development as well as front-end of Daps. They also monitor the stack running the dapps.

Core Blockchain Developer

These developers focus on the architecture development of blockchain systems. They design their own consensus protocol and make most of the important decisions related to the blockchain. They monitor the network and design the architecture of the same. Core blockchain developers are also responsible for the security of their blockchain network.

Role and Responsibilities of Blockchain Developer:

• Research, design, develop, and test blockchain technologies.
• Brainstorm and help evaluate applications for new tools and technologies as they continually evolve.
• Maintain and extend current client- and server-side applications responsible for integration and business logic.
• Collaborating with managers to determine blockchain technology needs and envisaged functionalities.
• Maintaining client and server-side applications.
• Optimizing and securing blockchain applications by integrating new tools and technologies.
• Taking into account the current blockchain technologies and cryptography methods.

Blockchain Developer Skills:

Blockchain developers have many responsibilities. To handle those responsibilities well, they must possess certain skills as well.

Cryptography:

Cryptography is the study of protocols that prevent unwanted parties from accessing your data. There are several essential concepts in cryptography that you should be familiar with as you will need them during blockchain development.

Data Structures:

To become a blockchain developer you need to have extensive knowledge of data structures. This is because blockchain developers regularly work with different data structures as they need to build and implement networks.

Blockchain Architecture:

To become a blockchain developer, you must be familiar with blockchain architecture. You should know what a ledger means in a blockchain, what is consensus, and how smart contracts work.

Web Development:

As a blockchain developer, you will be developing web apps in most cases. Learning web development will you familiar with all its aspects, and you can create robust web apps that use Blokchain technology using this knowledge.

Java:

Java is popular among blockchain developers due to its many properties. It is easy to learn, but it is capable of developing many complex solutions.

C++:

C++ is a popular language among blockchain developers. You can do a lot of things related to blockchain with its help. The creators used C++ to create Bitcoin Core, so it’s definitely a must-see for any aspiring blockchain developer.

Python:

Python is one of the most popular programming languages on the planet. It is versatile, and its various libraries enable you to use it for both front-end as well as back-end development. So you should also familiar yourself with Python.

You can learn JavaScript, Ruby, and C# in addition to the languages mentioned above. The ability to learn and work with multiple languages is one of the important blockchain developer skills.

What Blockchain Developer do?

Blockchain software developers build applications based on the blockchain architecture and protocol. Blockchain software developers create dapps or decentralized applications. They are responsible for the front-end as well as back-end development of Dapps. They also monitor the stack running the dapps.

Blockchain developers enable secure digital transactions by the system to record and store Blockchain data which prevents changes or hack.

• They design secure blockchain technologies.
• Develop application features and interfaces.
• Maintain client and server-side applications.

At present, Blockchain is considered one of the most revolutionary technologies as it transforms the way we interact, transact, and share information. Many technocrats and Blockchain Experts also believe that it is going to be the most disruptive technology in the next decade.

Today, this technology is not only used by tech giants, enterprises, federal agencies, and even startups have started adopting Blockchain. In fact, they are looking for Certified Blockchain Experts and are considering certified professionals over the non-credential peers.

Thank you!!

The post How to Become a Blockchain Developer? appeared first on scmGalaxy.

Features of python

• Easy to code
• Free and open Source
• Object-Oriented Languages
• GUI Programming supports
• High-level Language
• Extensible Feature
• Large Standard Library
• Dynamically Typed Language

Why Should You Learn Python?

Nowadays, Python has become one of the fastest growing and most popular programming languages in the world. Is it a good choice for your next project though? Python is versatile, it is easy to use and develop.

Moreover, it has a very vibrant community. You can easily find support from the best minds in the field. It is well-loved among both experienced programmers and beginners alike. There are many reasons to learn Python. Some of the reason to learn Python are:

• Versatile, easy to use and fast to develop
• Open source with a vibrant community
• It has all the library required
• Great for prototype (You can do more with less Coding)
• Fast Development speed
• Easy maintenance
• Not native to mobile environment
• Learning Python will keep you relevant
• Python is similar to English
• Python is widely used

How Long Does it Take to Learn Python?

If you’re looking to become a Python expert you have a much longer path ahead of you. In this article, we’ll just look at how long it takes to get a basic, well-rounded understanding of the Python language.

On average, for beginners it takes about 10-12 hours to learn the basics. This will get you enough to understand most lines of code in Python. If you plan on getting into data science or another specialized field, counting in months and years is more appropriate. If you spend your 5 to 6 months to this language, then this matter of time suited those who pan full time work in this.

To learn, plan is simple you should have to spend 2-3 hours a day on computer and practise it on daily basis. One day learn something and next day practise it with fully.

You may need to sacrifice the time you spend watching Netflix, but it’s well worth it for a stellar new career!

Career Opportunities in Python

Python is not only one of the most popular programming languages across the globe, but it is one that offers the most promising career opportunities as well. This demand for Python developers is increasing every year. There is a reason why this high-level programming language is so popular.

Python can be used in several areas, including testing, web development, app development and upgrades, and scriptwriting. If you acquire this skill, you will have more Python career opportunities than you can imagine.

Python Career Opportunities

So what are the options in front of you when you complete your Python learning? Here are a few job roles that you can fill:

• Python Developer

This type of jobs you can except after acquiring the skills of python, you have always open position for Python Developer.

What does a Python developer do? 

1. Building website
2. Resolve problems related to data analytics
3. Write codes that are reusable and efficient
4. Optimize data algorithms

• Data analyst

This particular job option is mainly for those who like to working with huge amounts of data and finding meaning in that data. This also a popular job role in this domain. There are many companies that are looking for people who can work with the large sets of data that they have access to.

• Product Manager

Product managers comes with an important role to play in this domain when it comes to helping businesses to understand the market and why building one product will be better than building another. Data is a very important part of the work they do. They study the market, research for new features related to a particular product or category, and advocate the building of certain products with facts. 

• Machine learning engineer

Nowadays requirement off this particular job role is by 330% in the last couple of years.

A machine learning engineer builds and trains machines, programs, and other computer-based systems to apply their learned knowledge for making predictions.

Why Python skill is essential for every Software Engineer?

Python is a very popular open-source software development language that offers enhanced process control capabilities. It is able to develop complex multi-protocol network applications

• The career opportunities for skilled professionals are increasing significantly with huge scope for career growth.
• The average salary of a Certified Python Developer is US$116,379 per year.
• There are more Job opportunities for Python professionals in top MNCs when compared to other technologies.
• IT Operations, IT Monitoring, IT Support, & Data Centre teams.
• Professionals who aim to make a career in big data with Python, Professionals having experience of Programming, Software Testing Professionals, Software developers.

Python Job and Salary

This is the vast and most desire welcome opportunity provide to a Python skilled candidates.

If you are able to strike a balance, you will not have to think too much about your salary after that. You will have the opportunity to work with the world’s most popular names, such as Amazon, Accenture, Cognizant, Tata Consultancy Services Limited, and others. Your career will continue to grow as you gain more experience.

On an averagea senior software developer earn as much as Rs 2,000,000 per annum. Other hand Web developer with Python skills can also earn in the range of Rs 8, 00,000 per annum. Other related job roles include lead software engineer (up to Rs 2,000,000 per annum), data scientist (Rs 7,00,000 per annum), machine learning engineer (Rs 6,70,000 per annum), data analyst (4,17,000 per annum), and more. 

The popularity of python increased among developers by the fact that Python is used by some of the biggest names in the world – Facebook, Netflix, Google, and Spotify, amongst others. This points towards one thing – As a professional skilled in python, you will have your chance of working with one of your dream companies. 

To make you this clear we shared you some that that According to Naukri.com, there were more than 75,000 open jobs for Python developers in India at the end of 2021. Similarly, the open jobs for Python web developers were around 7000 around the same time.

Conclusion

In this Article, we all discussed on point of a career in python. We provided you the enough information about the salaries what you can expect to earn in different job roles with Python skills We also discussed the options that you can choose as a skilled Python professional depending on your interests.

If you are curious to learn about Python, and make a good career with this skill then I would suggest you please check out DevOpsSchool.com more information.

The post What is python? appeared first on scmGalaxy.

The post Agile Software Development appeared first on scmGalaxy.

The post Why DevOps skill is very important to have? appeared first on scmGalaxy.

The post How DevOps is enhancing the capability of software development? appeared first on scmGalaxy.

The post How DevOps course is enhancing the capability of software development? appeared first on scmGalaxy.

This post is about using ANT to perform some of the most common source-control related tasks such as export, tagging, and branching. I am using ANT version 1.7.0 and SVN Ant version 1.1-rc3, bound against Subversion 1.4.0.

The related software can be downloaded here:
1.    SVN Ant = http://subclipse.tigris.org/svnant.html
2.    ANT = http://ant.apache.org/
I shall start with build.properties, which lists a few key/value pairs used in our SVN Ant task build file, referred as svn-tasks.xml:

Content of build.properties:
####START of SVN Properties ####
svn.repository.url=http://xyz.com/repos/somereponame
svn.project.base.path=someprojectname
svn.username=user name to access repo
svn.password=password to access repo
#This shall be name of the tag,
#This property should always be updated before build starts
#This property shall be used to export
tag.name=SOME_TAG_NAME_12222008
#This shall be name of new branch,
#this property should be used only when new branch is to be created
new.branch.name=NEW_BRANCH_12222008
####END of SVN Properties ####
Content of svn-tasks.xml:
<property file=”build.properties”></property>

<!– SVN and SVN-ANT Tasks properties –>
<property name=”svn.repository.url” value=”${svn.repository.url}”/>
<property name=”svn.project.base.path” value=”${svn.project.base.path}” />
<property name=”svn.base.url” value=”${svn.repository.url}/${svn.project.base.path}”/>
<property name=”svnant.lib.dir” location=”svn-ant-lib”/>
<property name=”svnant.javahl” value=”false” />
<property name=”svnant.svnkit” value=”true” />
<!– SVN and SVN-ANT Tasks properties –>

<!– *************************************************************** –>
<!–   Set-Up of SVN-ANT classpath                                   –>
<!– *************************************************************** –>
<path id=”svnant.classpath”>
<fileset dir=”${svnant.lib.dir}”>
<include name=”**/*.jar” />
</fileset>
</path>

<!– *************************************************************** –>
<!–   Loading of SVN task                                           –>
<!– *************************************************************** –>
<typedef resource=”org/tigris/subversion/svnant/svnantlib.xml” classpathref=”svnant.classpath” />

<!– *************************************************************** –>
<!– tool-availability: Determine if SVN-ANT is available.           –>
<!– *************************************************************** –>
<target name=”tool-availability”>
<available resource=”org/tigris/subversion/svnant/svnantlib.xml”
classpathref=”svnant.classpath”
property=”available.svnant”
/>
<echo message=”SVN-ANT is available = ${available.svnant}”/>
</target>

<!– **************************************************************** –>
<!– does-svnant-exist: depends on tool-availablility and     –>
<!–                    displays error message                                   –>
<!– ***************************************************************** –>
<target name=”does-svnant-exist” depends=”tool-availability”>
<fail unless=”available.svnant”>
SVN-ANT is not available, cannot perform tagging or checkout/export svn ant task.
</fail>
</target>

<!– ****************************************************************** –>
<!– svntag: performs tagging using properties from                              –>
<!–         build.properties and uses SVNANT tasks                              –>
<!– ******************************************************************* –>
<target name=”svntag” description=”tags individual project using svnant task”>
<property name=”svn.tag.message” value=”Tagging Project ${project.name} with tag name ${tag.name} from trunk “/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/trunk/”/>
<property name=”dest.url” value=”${svn.base.url}/${project.name}/tags/${tag.name}”/>

<echo message=”${svn.tag.message}”/>
<echo message=”${src.url}”/>
<echo message=”${dest.url}”/>

<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}” username=”${svn.username}” password=”${svn.password}”>
<copy srcUrl=”${src.url}” destUrl=”${dest.url}” message=”${svn.tag.message}”/>
</svn>
</target>

<!– ****************************************************************** –>
<!– svnexport: performs export using properties from                            –>
<!–            build.properties and uses SVNANT tasks                           –>
<!– ****************************************************************** –>
<target name=”svnexport” description=”exports individual project using svnant task”>
<property name=”svn.tag.message” value=”Exporting Project ${project.name} with tag name ${tag.name}”/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/tags/${tag.name}”/>
<property name=”destPath” value=”${dest.path}”/>
<echo message=”${svn.tag.message}”/>
<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}” username=”${svn.username}” password=”${svn.password}”>
<export srcUrl=”${src.url}” destPath=”${destPath}/${project.name}”/>
</svn>
</target>

<!– ****************************************************************** –>
<!– svnbranch: creates a new branch using properties from                       –>
<!–            build.properties and uses SVNANT tasks                           –>
<!– ****************************************************************** –>
<target name=”svnbranch” description=”creates a new branch for individual project using svnant task”>

<property name=”svn.branch.message” value=”Creating new branch for
Project ${project.name} with new branch name ${new.branch.name} from
trunk”/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/trunk/”/>
<property name=”dest.url” value=”${svn.base.url}/${project.name}/branches/${new.branch.name}”/>

<echo message=”${svn.branch.message}”/>
<echo message=”${src.url}”/>
<echo message=”${dest.url}”/>

<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}”
username=”${svn.username}” password=”${svn.password}”>
<copy srcUrl=”${src.url}” destUrl=”${dest.url}” message=”${svn.branch.message}”/>
</svn>
</target>

Link: http://java.dzone.com/articles/how-use-svn-tasks-with-ant

The post How to Use SVN Tasks with ANT ? 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.

Software development has traditionally suffered from producing end products with a definite lack of inherent quality. The symptoms of this quality lack are listed here:

• Software development projects are often delivered late and over budget.
• Often the delivered product does not meet customer requirements and is never used.
• Software products simply do not work right.

As we look into the symptoms of our software development malaise, five principal issues related to software development arise.

Lack of Visibility
Software is conceptual in nature. Unlike a bridge, a building, or another physical structure, it is not easy to look at software and assess how close it is to completion. Without strong project management, “software is 90% complete 90% of the time.” Through the adoption of SCM policy and the definition of the configuration management model of the software under development, all CIs, components, and subcomponents are immediately visible for versions, releases, and product families.

Lack of Control
Because software is inherently intangible, it is also more difficult to control. Without an accurate assessment of progress, schedules slip and budgets are overrun. It is hard to assess what has been accomplished and what remains to be done. SCM provides the mechanism for controlling the project through measuring the amount of effort compared to the project management plan and estimating the future effort based on past work.

Lack of Traceability
A lack of linkage between project events contributes to project failures. The main benefit of SCM is providing the traceability among versions, releases, and product families. The value of this traceability is enormous when a problem arises in one release or product family that impacts other client releases and products. Making one change and promoting that through the entire product software base is an incredible cost savings in time, money, and client good will. A lack of linkage between project events contributes to project failures where solving one problem either exacerbates a problem in another area or fails to fix the same problem elsewhere. A traceability thread allows management to examine the chain of events that caused a project to encounter difficulty as an integral process within the auditing capability of SCM. A project becomes a year late one day at a time unless the effort reported on the schedule maps to the actual work being done and traced within the software configuration management system.

Lack of Monitoring
Without traceability and visibility, monitoring of software development projects becomes extremely difficult. Management cannot make informed decisions, and thus schedules slip further and costs continue to exceed budget.
There is no way to monitor a project when the project manager has no tools to look into the actual product development within the project. SCM provides the tools that open up the process to external monitoring. With SCM in place and a policy of traceability and visibility accepted, monitoring of software development projects becomes a simple part of the overall project management task. Management makes informed decisions avoiding schedule slips and budget excesses through the monitoring available with SCM tools and the integral workings of the CCB.

Uncontrolled Change
Software is very malleable; it is idea-stuff, and customers constantly have new ideas for it. People would rarely ask a bridge constructor to make the kinds of changes midproject that software customers tend to request. The impact of such changes can be just as great. All SCM tools, along with the CCB, support a mechanism for appropriate change control.

SCM Interacts with Verification and Validation
SCM is most important, and most often neglected, during V&V activities, which include software testing. It is employed in tracking which module versions are included in a particular system build, as well as which tests have been run. The results of the tests are tied directly to the modules or subcomponents being tested. Many times there are “action items” resulting from the tests. SCM tracks the action item status, so overall system status can be assessed well before final builds and releases are done.
Verification and validation testing are supported through the four basic SCM processes: identification, control, auditing, and status accounting. Let’s look at examples of V&V testing in the context of each of these components.

SCM Identification Benefits to V&V

• Automatic preparation of release notes
• List of changed software modules
• Definition of development baseline
• Generation of incident reports
• Definition of operational baseline
• Control of the configuration item identification
• Management of CCB meetings
• Prioritization of test and incident issues
• Establishment of turnover dates
• Approval of audit and test reports
• Approval of incident report resolutions

SCM Auditing Benefits to V&V

• Comparison of new baseline to previous baseline
• Assurance that standards have been met
• Audit trail of the testing process (verification, validation, and acceptance) of the software system
• Documentation of experience with technical aspects of system engineering or software engineering

SCM Status Accounting Benefits to V&V

• Logging and tracking of incident reports
• Publication of CCB minutes

With all of these potential benefits of SCM, project managers must address real-world considerations. Management commitment is the real key to implementing SCM on a specific project in a given organization. By treating the implementation of SCM as a project, the project plan must start at the top to secure commitment to checks and balances. Now is the time to bring out the organization’s list of project disasters to draw on management experience with their previous software project difficulties. If there are no historic disasters in the organization, or if it is inappropriate to discuss them, refer to literature articles that provide accounts of project disasters (refer to the Web resources at the end of this chapter). Finally, after putting a notional return-on-investment financial argument in place, explain the intangible benefits of SCM.
One of the major sources intangible benefits is auditing. Auditing can be a heavy consumer of configuration management resources, and management may question the benefit of this kind of expenditure. Auditing pays for itself through the avoidance of larger, unnecessary expenses. Savings of 100:1 (large projects) or 4–6:1 (small projects) are obtained by finding and fixing problems early in the life cycle. The auditing process in SCM uncovers the areas where a little more effort or control will result in higher-quality software products and lower overall project costs.
There can be audit compromises to reduce costs. As a project manager, plan audits based on both the phases of the life cycle and the frequency of builds, versions, releases, and product families. Auditing each baseline in a project while reducing the depth of each audit maintains some traceability with loss of visibility.
Eliminating one or more audits (installation baseline, for example) maintains visibility but slightly impacts traceability.

The post The symptoms of our software development malaise appeared first on scmGalaxy.

SCM Tools
The minimum features for SCM tools are closely related to the task of handling the different product deliverables produced within the project software engineering process. Tool requirements and selection criteria are based on a series of features that provide a consistent look and feel with state-of-the-art software development environments. An SCM tool must have multiuser support, an intuitive graphical user interface, conformity to the organization’s development environment, scalability, flexibility in integrating other software development tools, ease of setup, modifiable models, process management, extensive support for the development phase, and management of nondevelopment objects.

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.
A quick search of the market in SCM tools provided the list of potential candidates for the tool as shown in Table 31–1.

Table 31–1 SCM Tools

From the list, four were picked as possible commercial products that would meet the project’s requirements:

• PCMS is an established product with strong all-round capability to manage the development of complex software projects over a wide range of platforms. Based on information in the public domain, PCMS has shown the greatest level of product development.
• ClearCase is the dominant commercial SCM-tool in Unix development environments and is rapidly moving into NT client/server market development environments. It has achieved this principally by providing developers with transparent tools supporting their work environment and culture. The introduction of ClearTrack extends the all-around capability of the tool set by supporting the management and documentation of changes. After the recent liaison between Rational Software Corporation and Atria Software, Inc., an interesting merge of features between the object-oriented design tool Rational Rose and ClearCase may be expected.
• Continuus/CM toolset is characterized by a strong embedded support for process, and its breadth of SCM coverage. The task-based process model is an intuitive approach to the management of change. Distributed development via direct links or over the Internet is simple to set up and operate. However, working across low-grade communication networks is difficult to set up and administer.
• PVCS is the market-leading system for software configuration management by numbers sold. It is simple to use and has stood the test of time. Intersolv has gradually added functionality to Version Manager with associated products such as Tracker, Configuration Builder, and Gateway, and by integrating PVCS with many third-party tools.

Following an example from SEI, we formed a ranking system for comparing the tools. Table 31–2 shows the rating for the considered tools.
SEI Template for Ranking CM Plans.
Source: SEI, from Configuration Management Plans: The Beginning to your CM Solution.
The result of this first ranking allows one of the potential tools, PVCS, to be dropped. This would then leave three for the project manager and tool evaluation team to take a more in-depth look. Note that there has been no discussion of price at this time. Once the technical decision has been made, the cost decision should follow. Do not introduce price early in the evaluation. If there is discomfort with the technical capabilities and life cycle coverage of a tool, adding in a cost variable will only further confuse the decision. Many software project tools become less desirable after full life cycle cost is analyzed and estimated. Make the technical decision first.

Comparison of Four Commercial SCM Tools

As a final note on tools, working strictly in a Microsoft development environment with Microsoft tools working under Visual InterDev, Visual Source Safe (VSS) is included as an integral part of the tool suite. VSS is an adequate SCM tool for small commercial product development that is strictly targeted to Microsoft platforms. If you’re developing on Microsoft platforms and have delivery targets on Linux or Unix, investigate the use of WinCVS. WinCVS is a shareware package that is very capable in providing large-project, multiplatform SCM. It compares favorably with most and betters some commercial SCM tools.

The post What are the minimum features for SCM tools? – SCM Tools Essential Features appeared first on scmGalaxy.

SCM benefits an organization in four areas: control, management, cost savings, and quality. These four benefits are mapped to an organization’s overall goals and objectives when the decisions are made to bring a SCM tool in-house. The features of a SCM tool further support these benefits.
SCM Benefits the Organization in Four Major Ways

Control
Control in SCM provides the ability to review, approve, and incorporate changes into a configuration item. There must be one controlling SCM tool so that there is only one set of training, license management, installation, and user procedures. All project personnel use the tool. Inherent in the tool is a standardized, measurable process for change. Integrity maintenance of CIs is enforced throughout the product life cycle. The tool permits only controlled change to the baseline CIs, and all changes are tracked.

Management
Management in SCM is concerned with the automation of identifying and guiding configuration items through their life cycle to final assembly as part of product and delivery. Identification of CIs through a unique naming convention allows version, release, update, and full change tracking. Baselining of CIs with the ability to produce product deltas from the baseline satisfies requirement and schedule changes along with product family support. Rapid reviews and audits of CIs are accomplished through the analysis of historic information collected. Project status reporting is accomplished in a clear and consistent format based on SCM collected information on all CIs under configuration management.

Cost Savings
Cost savings are realized across the entire product development life cycle with SCM. Maintaining product integrity through defined, tracked, and audited CIs provides a managed bill of materials for the product released to customers. Cost savings scale with SCM use and application across applications. This scaling is dependent on the depth of control needed for each application product release tree. Deep combinations for product families can be analyzed for risk exposure and cost savings directly impacted by the amount of configuration management applied. Side effects are reduced through controlled change by understanding the impact on all versions and releases. Accurate and repeatable release control is produced in a repeatable fashion over entire product families for all customers and users.

Quality
Software development is a people-intensive activity, and quality must be considered at every person-to-tool interface. Ensuring a high-quality work environment must address the process of building software products in an automated fashion. This must include tracking CIs to the tools that produced them and the clients that ultimately receive the product. Measuring the end product to ensure high quality is done through tracking the changes made to a product throughout its life cycle. Repeatable management and change control in a documented and measured fashion allows accurate estimation of future efforts. Quality is an ongoing process. The lessons learned in one product must be transferred to new, related products and entire product families.

The post SCM Benefits the Organization in Four Major Ways – SCM Process Benefits appeared first on scmGalaxy.