Lesson 1 of 5
Features as the unit of change
11 min
Every SAP program eventually has to answer one plain question about each change: what exactly is going to production, and how do we know it works? In SAP Cloud ALM the object that answers it is the feature. SAP describes a feature as the vehicle that deploys functionality across your landscape: it holds the landscape information, the transport containers for the changed objects, the technical change documentation and the history of every status change.
A feature is deliberately different from a user story or a project task. User stories and tasks describe work; they are not transport-related. A feature is transport-related: it is the thing that moves. One feature can collect several user stories and tasks, and it is linked to the requirement it delivers. When every feature for a requirement has been confirmed in production, Cloud ALM treats the requirement as complete.
The feature lifecycle
A feature moves through a fixed set of statuses. A new feature starts In Specification, where the technical design is written. In Implementation is where transports are created or assigned and changes are built and deployed to test. In Testing means the change is ready to be tested. Successfully Tested records that it passed. Ready for Production is the approval for production, and Deployed confirms it reached production. Not Planned parks a postponed feature and can be set from, and reversed back to, In Specification.
- In SpecificationDesign written; transports may be created or assigned
- In ImplementationBuild, release tasks, deploy to the test system
- In TestingTesters execute linked test cases in QAS
- Successfully TestedTesting passed; no new transports can be created
- Ready for ProductionApproved by a Change Manager or Project Admin
- DeployedImported into production and confirmed
The statuses are not just labels. Cloud ALM uses them to switch transport actions on and off. You can create and assign transports early in the life of a feature, but once it reaches Successfully Tested you can no longer create new transports for it, and deployment to production is only possible in Ready for Production. That is the control: a feature cannot quietly grow new content after it was tested, and it cannot reach production without passing the approval status.
Who changes a status
Status changes need the right role. SAP's learning material states that approving a feature for production, which sets it to Ready for Production, requires the Change Manager or Project Admin role. That lets you run a four-eyes principle: the developer who built the change cannot push it to production on their own. At Contoso Motor Co., Luis, the cutover and release manager, holds the Change Manager role; developers and functional consultants do not.
| Feature content | What to record | Why it matters at sign-off |
|---|---|---|
| Title and description | A meaningful title; rich-text description with the technical design | Reviewers can see what is being changed without opening transports |
| Requirement link | The requirement the feature delivers | Traceability from business need to production |
| User stories and tasks | The build items inside the feature | Shows the work is finished, not just started |
| Priority, release, responsible, tags | Planning attributes; the release comes from a deployment plan | Lets Luis bundle features for a go-live |
| Transports | Created in or assigned to the feature | Proves which objects will move |
| History | Every status and attribute change, automatically | The audit trail of who approved what and when |
What a well-kept feature holds at Contoso.
What would you do?
Kenji, Contoso's ABAP lead, wants to create one feature called "Order to cash changes" for all 40 custom developments in that area, so he has only one object to manage. What should Luis advise?
- A feature is the deployable unit of change in Cloud ALM; user stories and tasks are the work inside it.
- Statuses run In Specification, In Implementation, In Testing, Successfully Tested, Ready for Production, Deployed (plus Not Planned).
- Statuses switch transport actions on and off; production deployment needs Ready for Production.
- Approving for production needs the Change Manager or Project Admin role, enabling four-eyes control.
Check your understanding · not graded
Lesson check
1. Which Cloud ALM object is transport-related?
2. In which status does a newly created feature start?
3. Which roles can approve a feature for production according to SAP learning material?
4. When is a requirement treated as complete in Cloud ALM?