Show TOC

Process documentationProcessing Normal Changes Locate this document in the navigation structure

 

You use this process to make normal changes in your maintenance landscape, and to implement features in your development landscape.

A normal change is a project-based implementation of a new functionality, or new features for a specific process, for example, for bigger changes that are released on a quarterly basis. Usually, normal changes do not comprise bug fixes.

Prerequisites

  • A request for change has been created and approved, and a change document of the type Normal Change has been created. The request for change has been released for development.

  • To be able to process the normal change, the assigned maintenance cycle needs to be in the phase Development with Release.

    Note Note

    If the phase is Development without Release, you cannot export anything. You can create transport requests and make changes in the development system, but you cannot release transport requests.

    End of the note.

Process

  1. The lead developer who heads a team of developers calls up the change document from his worklist in the Change Management work center or directly from the WebClient UI, and sets the status to In Development .

  2. The lead developer creates a transport request in the development system via the Transport Management assignment block. She adapts the relevant data in the popup, for example, the description for the transport request and whether it is a workbench or a customizing request. She additionally creates a task for each of the developers in her team.

  3. The developers log on to the development system via the Landscape assignment block. They implement the requested featuers in the development system.

  4. When the features have been implemented, the developesr release their tasks in the transport requests in the transport organizer transaction (se09) in the development system.

  5. The developer indicates that she has completed the change by choosing   Actions   Complete Development  .

    She then saves the change document.

  6. The system creates a transport of copies and sets the status of the change document to To be Tested. The changes are transported to the test system.

  7. The lead developer assigns the change document to the IT operator to dispatch it to a tester.

  8. The tester starts testing the correction by logging on to the test system via the Landscape assignment block.

    He checks the change in the system.

    Note Note

    The transport of copies needs to be in the test system, for the tester to see and test the change. For more information, see Importing Transport Requests: Options.

    End of the note.

  9. In the change document, the tester chooses   Actions   Successfully tested  , to indicate that the changed function has been tested, and can be imported into the production system. The change document is now in the status Successfully tested.

    If the test was not successful, the tester chooses   Actions   Reset Status to In Development  .

  10. After aligning with the change manager, the IT operator imports all transport requests into the production system. Via the document flow, he navigates to the task list and triggers the import to the production system.

    Note Note

    You can request the preliminary import of a normal change into a follow-on system. This means that the transport is carried out at once and you do not have to wait for related changes to be transported. Thus, the transport process for normal changes can be accelerated. For more information, see Preliminary Import of Normal Changes.

    End of the note.

    To be able to trigger the import, the maintenance cycle must be in the Go Live phase. Only then can the transport to the production system take place.

    Note Note

    You can change phases in the maintenance cycle via the Actions dropdown list in the change document.

    End of the note.

More Information