Hello me to choose SCM as a career

uma.arumugam created the topic: Hello me to choose SCM as a career
Hello Guys!
Please help me to tell me everything about SCM. I wanna make my career in SCM. so what should i know and what should i do for it.
Is Build and Release is a part of SCM or it’s different form SCM?

rajeshkumar replied the topic: Re: Helo me to choose SCM as a career
SCM consist for following branch.

1. Configuration Management aks version control management
Tools – SVN, Perforce, GIT, Clearcase CVS etc

2. Build Management
Tools – Jenkins, Anthillpro, Bamboo etc

3. Release Management aka deployment management
Tool – Cruise and many in-house tools

4. Packaging Management aka Installer
Tools: Wise, InstallSheild, InstallAnywhere etc…

There are various tools for each one of them. Important things is that you need to be aware of concept of each one of them. also, you need to focus
on scripting for various purpose such as ant, perl, python, shell, maven, make etc.

Small project has all mixed profile dedicated to one engineer but big and complex project has individual engineer assigned for each task. there are many books and web reference you can find over to web to know more about it.
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

uma.arumugam replied the topic: what is Build and Release
Thanks for my replying on my previous Question.
Now i want to know what is Build and Release and how to learn it for a small project, I also want to know about scripting.

rajeshkumar replied the topic: Re: what is Build and Release
Hi,

please go through this url en.wikipedia.org/wiki/Release_engineering and Related disciplines section.

Also, some books can be found in www.scmgalaxy.com/ebooks-collection/

if you want to learn scripting, you need to try for it 🙂
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

SCM Build and Release Engineer Jobs Website | Portal

scm-build-and-release-engineer-jobs-website

Build and Release Engineer Jobs | Build Engineer Jobs | Clearcase Administrator Jobs | Configuration Engineer Jobs | SCM Administrator Jobs | Release Engineer Jobs | Perforce Administrator Jobs | Subversion Jobs | Github Jobs | SCM Engineer Jobs |

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

General SCM Interview Questions – SCM Job Interview Kit

scm-interview-questions

 

General SCM Interview Questions – SCM Job Interview Kit

  • What do you think about configuration management?
  • What do you understand about Change Management?
  • branching methodologies and what currently theya re using it. Show with some example with pros and cons
  • Concept of Merging and Why do we need?
  • What do you think about build Management?
  • What are the key benefit of build Automation and what are the key inputs to automate the build process in the project?
  • Discuss about tools and technology which help to automate the entire build cycle.
  • What is Continuous Build Integration and How this is useful for the project?
  • What is daily build & nightly builds and what are the process need to set up to Automate & monitor consistently.
  • Explain in details for writing build sciprt for any project
  • What do you think about release Management?
  • Talk about Release Management on several platforms?
  • What do you understand about Packaging and Deployment?
  • How to Automate Remote Deployment of Builds on Development & Test Servers?
  • What is workflow management. exmplain this in details.
  • What do you understand about Code Coverage? Describe repective tools & utilities.
  • Describe the Integrate Packaging scripts & Test Automation scripts with build & Monitor build verification test status and tools.
  • How to co-ordinate with development team to increase their productiavity.
  • What do you understand about multisite project
  • How SCM team perform integration and co-ordination between Dev and QA
  • Explain Troubleshooting in Build Server and Process
  • Explain Troubleshooting in Configuration Server and Process
  • Explain Troubleshooting inMost popular java Comipler issues in build server
  • Explain Troubleshooting inMost popular C++ compiler issues in build server
  • software packaging tools if they will be packaging or writing the installations for the releases.
  • Backup your code daily with respect to SVN.
  • Overview of Batch Scripts and top 25 commands
  • Discuss about Web Servers and Application servers
  • What do you think about distributed and multi-site environment
  • Can you name some software development methodologies and describe them?
  • Agile attempts to minimize risk by developing software in short iterations.
  • Extreme Programming employs simplicity, frequent communication, constant customer feedback and decision empowerment.
  • Iterative development is a cyclical methodology that incorporates refactorying into the process.
  • Waterfall software development is a phased methodology. When one phase is complete, it moves onto the next phase.
  • What is an API?
  • What is a web service?
  • What the difference between a global and a local variable?
  • What are Bug /Issue Tatcking tools available and descibe them
  • How does Subversion handle binary files?
  • What is ADO?
  • What is polymorphism?
  • Plz Let me the Difference Between Bea Weblogic IBM Websphere

Perforce:

  • What are basic skills required for Perforce administration including Command Line info.
  • How we can develop Build summary reports for Mgmt team and what are the key inputs for report.
  • Explain the best practice for Setup process & maintain the Archive of software releases (internal & external) & license management of Third Party Libraries
  • Identify the Cdeployment tools for major/minor/patch releases in different environment.
  • Explain Red Hat Linux and some of daily used features.
  • Explain Perforce & Multisite
  • Concept of labeling, branching and merging
  • labeling, branching and merging in perforce

Talk about Release Process

Can you describe some source code control best practice?
# Use a reliable and dedicated server to house your code.
# Backup your code daily.
# Test your backup and restore processes.
# Choose a source control tool that fits your organization’s requirements.
# Perform all tool specific administrative tasks.
# Keep your code repositories as clean as possible.
# Secure access to your code.

Can you describe software build best practices?
# Fully automated build process
# Build repeatability
# Build reproducibility
# Build process adherence

CM tools Comparison

  • Difference Between CVS and SVN
  • Difference Between perforce and SVN
  • Difference Between perforce and Clearcasee
  • Difference Between VSS and TFSC
  • Difference Between perforce and MKS

 

 

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

Power Point PPT: Introduction To Software Configuration Management

software-configuration-management-introduction

Power Point PPT: Introduction To Software Configuration Management

 

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

Power Point PPT: Scm With Mks Integrity

scm-with-mks-integrity

Power Point PPT: Scm With Mks Integrity

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

Power Point PPT: Software Configuration Management And CVS

software-configuration-management-and-cvs

Power Point PPT: Software Configuration Management And CVS

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