To develop and provide add-ons, you have to set up a suitable system landscape and Cloud Foundry environment account structure.
You need a partner contract to create the account structure. The accounts for the upstream (add-on development, test, build) and downstream (providing add-on as SaaS solution) parts of the process need to be separated from each other and therefore are handled in dedicated global accounts. We refer to these as global accounts for development and production account. For more information regarding the development license, see SAP PartnerEdge Test, Demo & Development Price List. To find out more about production licenses, see SAP PartnerEdge: Resources for OEM Partners.
For in-depth information about the system landscape/account model, check out System Landscape/Account Model.
For the initial add-on delivery, you should create a development and test landscape following the guidelines mentioned in Concepts. Once backend and frontend development is completed, you can test the add-on implementation in a persistent test system. Upon successful completion of this step, set up a CI/CD server along with a Jenkins pipeline to execute the add-on build allowing for an automated and efficient assembly. This automated pipeline can then be reused transforming all upgrade and update activities into a straightforward process.
Once the add-on build/assembly is finished, you can release the add-on for installation/update. First, the add-on build is installed in a test system in the global account for development to verify that it works correctly. If successful, you can provide the add-on to customers.
Besides using add-ons for delivering software components to production systems, gCTS transports can be used as an alternative approach. It is used for transporting software components between different ABAP systems.