Fasten your seat belts: Flying the Oracle Development Cloud Service (4 – In Flight 1)

In the last part of the series Fasten your seat belts: Flying the Oracle Development Cloud Service (3 – Take Off – ROTATE) we finished the work on the first cloud workspace, a utility project holding framework extension classes we use in the upcoming development. We created a branch to add the build system we can use in the cloud as well as on the developer’s machine.
The developer checked in all his/her changes, but did not merge the branch back into the mainline development (master). This part describes how this action, called a merge request, is done. This action can be used as a quality gate to review the code the developer has build.
After logging into the Oracle Developer Cloud as developer we select the ‘Merge Requests’ tab of the project

Merge Requests

Merge Requests

where we create a new request by clicking on the ‘New Request’ button. In the next dialog we fill in the needed data
Create Merge Request dialog

Create Merge Request dialog

The target branch is the branch we like the feature branch to be merged into, in our case it’s the branch called ‘master’. If you have other branches you like to merge you can do this too and later merge the whole merged feature branches back into the master branch. The ‘review Branch’ is the branch we want the review on, in our case the ‘feature-setup-build’ branch. In the ‘reviews’ field we must add at at least one member of the team, but can add multiple members if we like. Each of the reviewers then gets a notification via e-mail that a review is waiting.

The developer can only wait now for the action of the reviewers. Sure he can do something else like start another task for the project🙂

The mails give some basic information about the request and the links to quickly access the cloud. After logging into the Cloud as reviewer the same ‘Merge Requests’ looks like

As we see, there now are the ‘Approve’ and ‘Reject’ buttons available for the Reviewer.
The reviewer should look at the changes made in the branch e.g. by looking at the commits for it.
Commits of the feature branch

Commits of the feature branch

As we don’t know what these files are doing, we reject the merge request

This will notify the developer who can and should act on the comment.

In this case the files are obsolete and can be deleted from the feature branch before merging (by the developer).

After changing the merge request by adding a hint that we delete the obsolete files, the reviewer again get some e-mails notifying him about this change.
Looking at the request after login, the reviewer approves the request and merges the branch into the master branch.

If we now look at the master branch we see the build files as part of the master branch.

One final thing to do is to switch the build system configuration from the feature branch to the master branch. When we started working on the feature we set up the build system to use the feature-setup-build branch. We now switch the build setup to use hte master branch.

This concludes this part of the series. Next we build a simple ‘normal’ ADF application in the cloud, applying what we have learned so far.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s