Step 3: Provisioning application instances and managing object changes

In the following, steps 3.1 through 3.4 are done by developers and testers, and steps 3.5 through 3.7 are done by team administrators and additional reviewers of the team that owns the originating application.

Step 3.1: Provision an application instance in a team's environment

You can provision a new application instance by specifying an instance name and selecting the subsystem type, the name of the application that you want to create an instance from, one of your teams, and an environment that is assigned to the team. The subsystem on which the instance is provisioned will be selected automatically by the system if more than one subsystem of the same type is assigned to the selected environment. After an application instance is provisioned to the selected environment, you can use the built-in SQL processor to run an SQL query against an application object in the instance to verify successful provisioning.

Step 3.2: Change the instances in that environment

After an application instance has been provisioned, you can use that instance on your work. To modify an application object included in the instance, an object definition source editor is provided for you to make changes as you like. Any syntax errors are indicated with icons for immediate feedback. If your change does not comply with the site rules that are associated with the application or the environment, one or more error or warning messages will be displayed.

Step 3.3: Apply the changes to the provisioned objects and test them

When you have finished editing an object definition, click Apply object changes to apply the changes to the provisioned object. You can modify more than one object and apply all the changes in a single operation by clicking Apply all changes. You can optionally use the built-in SQL processor to run SQL queries against the changed application objects to verify the changes.

Step 3.4: Submit a pull request for the changes

When all the work related to the application instance is completed, you can request that your changes be merged to the originating application. To submit a request, open the instance details page and click Create pull request. The pull requests that you submit are displayed in the Open pull requests widget on your Unified Experience Dashboard.

Your pull request must be reviewed and approved before it is merged to the originating application. All team administrators of the team that owns the originating application are automatically assigned as default pull request reviewers. The pull request submitter can add additional reviewers from a list of the team members of the application-owning team.

Step 3.5: Review the pull request

When a pull request is submitted, the request is displayed in the Pull requests to review widget of the reviewers' Unified Experience Dashboard.

They can review the changes to decide whether to approve or decline it. If there is any problem, they can decline the request so that the pull request submitter can make corrections or additional changes based on the comments provided by the reviewers. The pull request submitter can withdraw the pull request by using the Decline function.

Pull requests must be approved by at least one team administrator. Because team administrators cannot approve their own pull requests, at least two team administrators must be assigned to approve a pull request if team administrators themselves join the application development.

Step 3.6: Approve the pull request

If a pull request reviewer is good with the changes, the request can be approved. When at least one team administrator approves the pull request, the Merge button gets enabled, and the changes in the pull request will become ready to be merged to the originating application.

Step 3.7: Merge the pull request

A team administrator or an additional reviewer can click Merge to merge all the changes that the developer made to the application instance into the originating application.