Software Change Management Process 

Purpose

The SAP software change management process describes the flow of a software development starting from the local development up to the deployment on a central production system.

Overview of the Software Change Management Process

For the productive use of applications, you must set up a system landscape consisting of DTR workspaces and SAP J2EE Engines which take on different roles, such as development, consolidation, test and production. The local developments then find their way into the production system in accordance with the system roles.

If within the Software Change Management Guide we refer to workspaces, we always talk about DTR workspaces.

Prerequisites

You are working with the SAP NetWeaver Developer Studio and the Design Time Repository (DTR).

To be able to deploy from the SAP NetWeaver Developer Studio, you must configure one Developer Studio for each system.

You can execute all DTR functions using the command line client. However, you can also use the DTR Administrator Plug-In. In this case, you can execute all necessary administration tasks using the graphical user interface of the SAP NetWeaver Developer Studio.

Process Flow

Configuring Workspaces

Software Change Management starts when you create workspaces centrally in the Design Time Repository (DTR) for development in the scenario “Java Projects with Central Source File Storage”.

Creating or Importing Projects/Configurations

The development itself starts with creating local projects or development configurations on the development machine.

·        Scenario 1:

The developers synchonize their SAP NetWeaver Developer Studios with the workspace structure of the DTR and under this structure set up a development project in the SAP NetWeaver Developer Studio. In case any projects have already been defined centrally, the developers can import the existing projects into their environments.

See also: Scenario “Java Projects with Central Source File Storage” - Creating Projects

Synchronizing the Local Development Environment

In the next step, the developers synchronize their local development environments with the DTR and load the required resources (folders, source files, meta data) down to their PCs. They can now change the source code. The developers gather the changes in an activity, which is a storage place for logically related developments.

For more information on activities, see Modify a Versioned Resource.

Developing and Testing Locally

In the next development step, the developers develop and test their changes locally until they reach a stable state.

Checking In Changes

After successful tests of the changes in the local J2EE server, the developers check in the changed resources into the development workspace (DEV workspace) of the DTR. The sources are now visible to all other developers and are available for the build for the central development system.

Building and Deploying on the Central Development System

...

The system administrator synchronizes the central development server at given intervals with all changes in the DEV workspace of the DTR.

Then the system administrator starts the build and the deployment from within the SAP NetWeaver Developer Studio.

For more information, see Building and Deploying on the Central Test System.

Integrating Changes into the Consolidation Workspace

In this step, the system administrator copies all changes into the consolidation workspace (CONS workspace) which the developers checked in into the DEV workspace. The system administrators should define a schedule for this which determines the times at which changes are copied.

The system administrators must copy only those changes for which the previous build and deployment into the central development system were successful.

The system administrator uses function Integrate to... in the DTR perspective of the SAP NetWeaver Developer Studio or the DTR command line client to copy the changes. The integration step copies the changes gathered in an activity and integrates this activity into the assigned workspace.

For more information, see Integrating Changes into the Consolidation Workspace.

Freezing the Development State in the CONS Workspace

You can freeze a successfully consolidated state by documenting which activity was the last one integrated. Every activity receives a running number (Integration Sequence Number, ISN) for the workspace to which it was added, which, together with the workspace URL, defines a unique version of the workspace.

The highest ISN identifies the last integrated activity. To restore a stable state of the CONS workspace, execute Sync to date... on the time stamp of the respective activity.

We recommend to keep a list of consolidated software states, which are uniquely identified by the activity ISN and the workspace URL. At the same time, this list documents the development progress.

For more information, see Freezing Develoment States

Building and Deploying on the Central Test System

In analogy to the build and deployment into the central development system, the system administrator executes build and deployment to the central test system. To do this, the administrator synchronizes the active state from the CONS workspace.

Assuring Quality of the New Software Version

After the successful deployment into the central test system, a QA team tests and accepts the changed application.

Copying Software Changes into the Production System

After the QA testing of the changed software, the system administrator copies the sources from the CONS workspace, executes a build and deploys the build result onto the productive SAP Web Application Server.

For the production system you need no DTR workspace, because in a production environment you are not allowed to change sources. How to maintain system states is described under Maintenance and Support Packages.

After copying the changes into the production system, the system administrator can copy the next sequence of changes to the software into the consolidation workspace.