Show TOC

Process documentationProcessing Normal Changes

 

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 request for change (new functionality, new feature in existing functionality, or corrective activity for a minor defect in existing functionality). This change document is used to facilitate the development, testing, and approval of the change(s) while aligning the changes with an overall release strategy for the landscape and production system(s).

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 any changes. 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, 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. She can create several tasks at once.

  3. The developers log on to the development system via the Landscape assignment block. They implement the requested features in the development system and save their work to the tasks assigned to them by the lead developer.

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

  5. The lead developer indicates that she has completed the change by choosing Start of the navigation path Actions Next navigation step Pass Normal Change to Test End of the navigation path.

    She then saves the change document, and the status of the change document changes to “To be Tested”.

  6. In the TMS infrastructure of the managed landscape, this triggers the creation and release of a transport of copies, with the content of the original transport request.

  7. The transport of copies is added to the import buffer of the test system and is imported into the test system with the next execution of the import job for the project .

    Note Note

    The advantage of using transports of copies is that even when the objects are changed several times, only one transport request (that is, the original transport request) is queued in the buffer of the production system. Test transports can only be imported into the test system, not into the production system. Therefore, the production buffer is not filled up with erroneous transports that will never be imported into the production system. The only transport requests that are added to the production buffer are those that are to be imported into the production system.

    End of the note.

  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 test system.

    Note Note

    The transport of copies needs to be imported into 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 Start of the navigation path Actions Next navigation step Confirm Successful Test End of the navigation path, to indicate that the changed function has been tested, and can be imported into the production system. Setting this action triggers the release of the transports associated with the normal change for import to the test system. The change document is now in the status Successfully tested.

    If the test was not successful, the tester chooses Start of the navigation path Actions Next navigation step Reset Status to In Development End of the navigation path.

  10. There are two options for the further process:

    • The tester requests the preliminary import of the normal change.

      Note Note

      You can request the preliminary import of a normal change into a follow-on system. This means that the import of the transport(s) associated with the normal change is carried out at once, independent of any project import into the follow-on system. Thus, the import process for normal changes can be accelerated. For more information, see Preliminary Import of Normal Changes.

      End of the note.

    • The change manager chooses Start of the navigation path Actions Next navigation step Set Production Status End of the navigation path.

      The IT operator triggers the import manually from the task list of the project. Via the document flow, he navigates to the task list and triggers the import to the required system. All transport requests are imported into the test system and then into the production system. To be able to trigger the import into the production system, the change 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.

    End of the note.

More Information