In part three of the series about the Oracle Developer Cloud we start working on a project as a member of a team in the developer cloud.
Before starting a new project some basic ground has to be covered. What architecture and technology should the project use as well as which package path to use. For the technology the the decision is easy as we want to use ADF. For the architecture we can choose on one of the patterns outlined at ‘Angles in the architecture’.
A good starting point is to introduce a for every ADF project, regardless of the architectural pattern, is a framework extension project (see ‘Extending a Helping Hand’). So we start with this too.
As a developer can’t create a new repository in a cloud project, we have to do this as a user with admin rights.
The first thing to note is that you should create an empty repository (unmark the ‘Initialize repository with README file’). If you initialize the repository with a README file, the developer can’t later just push his initial local version of the JDev workspace into the remote repository. The local repository has be updated with the README file first.
Now that the remote, empty repository exists we switch roles and work as a developer. For this we use a different login as a user who only has developer rights in the Oracle Developer Cloud.
Before the developer uses the new repository he creates a new workspace or project. We create a workspace for the framework extension library.
Next we add the ‘ADF Model Runtime’ library to the project and then the framework extension classes to the workspace.
Right now we don’t need to add or change any of the code in the created classes. If we later need to add some global functionality we come back to these classes. The next thing to do is to create an ADF library from the created classes
To make the new library available for other projects you can create a new file system connection using the same path we specified in the deployment descriptor
Later we come back to this step as we see that we have to change it a bit to make it work in the cloud. Right now we leaf it as is as this shows how you normally would do this in a normal project.
The next thing to do is to initialize a local GIT repository and push this to the Oracle Development Cloud repository as the initial master
and then push the local master branch to the Oracle Developer Cloud repository. For this we use the repository URL we get when we log into the cloud as the developer
Using this URL we push the local repository to the remote one
to finally see the changes in the cloud
With the basics covered we have to make another decision:
How to define the workflow for changes to make to the project sources.
Should all team members work on the trunk (called the mainline) or should each member use a branch to work on (called a feature branch). Both of these practices have their supporters and naturally opponents. The first is more CI like per definition. Feature Branches on the other side are not CI by the definition, as the code is not continuously integrated into the main line. This dispute is not for this post and may be not for this blog. Anyway, lets start with feature branching.
This allows us to show a feature of the Oracle Developer Cloud as it allows for code reviews which are mostly used if you work with feature branches, but can be used for the other practice too.
Feature: add build files
The feature we implement is to setup a build system for our framework extension project. We name the feature ‘feature-setup-build’
We learned in part 1 that the Oracle Developer Cloud provides a Continuous Integration server (CI). We plan to use this CI server to build our library whenever the code changes. For this we need to use ANT or Maven as the build system. For this project we choose ANT and can now build the needed build.xml files from the project
To finish this part we add the new files to our local repository and then push them to the remote as a new branch.
We push the local changes to the remote repository in the cloud using the same branch name
We had not looked into the created build.xml file or the build.properties files, we had them just created and pushed them into the repository. Question is, will they work?
Let’s try it on the local machine first.
Now we can run the ANT target ‘all’ which is the default one.
Well, as JDev 12.1.3 has somehow eliminated the ANT tool bar buttons running ANT on a project is a bit cumbersome (hopefully the ANT build buttons are back with the next release)
OK, this works like a charm.
As this post is already very long, we split the take off into two parts, V1 and ROTATE. This concludes part V1. Next time we make the necessary changes to the build files to integrate them to the clouds build system and start the CI process.
Note: for those who wonder about the terms V1 and ROTATE:
– V1 is the maximum speed at which an aircraft pilot may abort a takeoff without causing a runway overrun
– ROTATE or Vr is the speed of an aircraft at which the pilot initiates rotation to obtain the scheduled takeoff performance