High-level Best Practice Six(6) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first five areas and there practices are already discussed.

Process

- 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. 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.
- In order to make propagating logical changes from one codeline branch to another easy, tracking change packages has a benefit. 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.
- SCM process should be able to distinguish between "What to do" and "What was done".
- 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.
- 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.

High-level Best Practice Five(5) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first, second, third and fourth area and there practices are already discussed.

Builds

Builds are necessary to construct software from source files. The high level practices involved with this workspace are :
- In a build, the only inputs that are needed are the source files and the tools that are used. There is no place for procedures or yellow sticks. If setup procedures are there, automate them in scripts. If manual setup is there, document them in build instructions.
- There are chances that the input list is incomplete if the software cannot be build from the same inputs. So, the input list needs to be checked.
- When you are organizing original source files in a directory, you need to ensure that already built objects are kept away and do not contaminate the source files. Built objects (those files that get created during the building process) should be located in a different directory, away from the original source files (which are the files that have been created through a tool such as a code editor, or through notepad, or through code generation tools).
- Developers, test engineers, and release engineers should all use the same and easily available build tools.
- Build should be done often as end-to-end builds with regression testing (“sanity” builds) reveal integration problems introduced by check-ins and they produce link libraries and other built objects that can be used by developers.
- Build outputs and logs, including source file versions, tools and OS version info, compiler outputs, intermediate files, built objects, and test results should be kept for future reference.

High-level Best Practice Four(4) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first, second and third area and there practices are already discussed.

Change Propagation

Propagating file changes across branches needs to be managed. The practices involved with this work space are :
- Do not delay to propagate a change. 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.
- 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.
- Changes can be propagated by the owner of the target files, the person who make the original changes, or someone else.

High-level Best Practice Three(3) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first and second areas and there practices are already discussed.

Branching
In Software Configuration Management (SCM) systems, branching allows development to proceed simultaneously along more than one path while maintaining the relationships between the different paths. A branching strategy consists of the guidelines within an environment for the creation and application of codeline policies. There are different tools that support branching Creating a branching strategy consists of :
- identifying the categories of development that can be easily characterized,
- defining the differences and similarities between them,
- defining how they relate to each other, and
- expressing all of this information as codeline policies and branches.

High Level Practices associated with branching workspace are :
- Branch only when necessary.
- Don’t copy when you mean to branch.
- Branch on incompatible policy.
- 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.
- Branch instead of freeze.

High-level Best Practice Two(2) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first area and its practices are already discussed.

The Codeline
It is a set of source programs or files required to develop a software. Codelines are branched, and the branches evolve into variant codelines embodying different releases.
The best practices are :
- Give each codeline a policy : It is the essential user’s manual for codeline SCM. The policy of the development codeline should state that it is not for release or the policy of the release codeline should state that it is not for testing or bug fixing. It specifies the check-ins for the codeline.
- Give each codeline an owner : After the policy is defined for a codeline, there would be situations where the policy is inapplicable or ambiguous. When the developers face these ambiguities, they will turn to the person who is in charge of the codeline. There has to be a owner of the codeline because if there would be no owner, the developer will create their own workarounds without documenting them.
- Have a mainline : A mainline 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.

High-level Best Practice One(1) in Software Configuration Management

Software configuration management (SCM) is a set of activities that are 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 changes that are imposed, and auditing and reporting on the changes that are made.
Software Configuration Management Best Practices are the techniques, policies and procedures for ensuring the integrity, reliability and reproducibility of developing software products.
When implementing SCM tools and processes, you must define what practices and policies to employ to avoid common configuration problems and maximize team productivity. There are six areas of SCM deployment, and some coarse-grained
best practices within each of those areas.
- Workspaces: It is the area where the engineers edit source files, build the software components they’re working on, and test and debug what they have built. The best practices for workspaces include:
. Don’t share workspaces.
· Don’t work outside of managed workspaces.
· Don’t use jello views: A file in your workspace should not change unless you
explicitly cause the change. A “jello view” is a workspace where file changes are
caused by external events beyond your control.
· Stay in sync with the code line.
· 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.

Load test Process and why to use JMeter ?

Why to use JMeter

Easy to install and use Free!
- Java — most platforms.
- GUI vs. command line.
- Just download and run.
Feature-rich Post forms
- Record from browser.
- Load test data from files.
- Add logic, variables & functions.
- Run one test from multiple machines.
- Test many protocols, not just HTTP.

Load Test Process

- System Analysis : Enable customers to convert their goals and requirements into a successful test script. You can create your own test Script consistently and carefully UI design allows you to create your own test easily.
- Creating Virtual User Scripts: Tester must emulate the real user by driving the real application as a client. JMeter support this by adding thread group element. This would tell the number of users you want to simulate, how often the users send requests, how many requests they send, what request (FTP Request, HTTP Request, and JDBC request) and validate that your application is returning the results you expect.
- Defining User Behavior : JMeter allows you to simulate human actions more closely by controlling how long JMeter engine delays between each sample so you can define the way that the script runs.
- Creating a Load Test Scenario : JMeter offers support for this step by assigning scripts to individual virtual user, tester can define any number of virtual users needed to run the tests, allowing the user to simulate concurrent connections to server application, enabling user to create multiple threads ( virtual user) executing different test plan and increasing the number of virtual users in a controlled fashion.
- Running Load Test Scenario : With JMeter you can run your tests in a very easy way.
- Analyzing Results : JMeter offers support for this step by:
. displaying the data visually (Graph Results).
. save data in file.
. allows user to see one multiple views of the data.
. displays the response from the server.
. shows the URL of each sample taken.
. listeners will show different sets of data.
. it can send email based on test results.