We are moving our internal development to Oracle Cloud production instance. This weekend I was going through build automation and deployment process with Oracle Developer Cloud Service. I would like to share few hints with you.
There are excellent video tutorials recorded by Shay Schmeltzer, I would not repeat here all the steps, will post only key steps in the process and few extra tips. Watch Shay's videos to get understanding how it works and how to configure Developer Cloud Service (UI was changed since then, but still all config steps are valid):
1. Using Oracle Developer Cloud Service for Git and code review with JDeveloper Applications
2. Oracle ADF Build Automation on the Oracle Developer Cloud Service
Download ADF 12.2.1.1/12.2.1.2 example configured with Ant scripts for build automation on Dev CS - ADFAltaApp.
JDeveloper/ADF version. When I run OJDeploy build in Dev CS (Developer Cloud Service), I can see in the log it prints version 12.2.1.1. This means currently Dev CS supports ADF up to 12.2.1.1:
Locally I prefer working on 12.2.1.2, since JDeveloper is more stable in 12.2.1.2. When I was trying to build code commited from 12.2.12, Dev CS complained it can't open project file. I have solved it by changing 12.2.1.2 to 12.2.1.1 in *.jws and *.jpr files (luckily my local JDeveloper 12.2.1.2 doesn't complain about it and continues to work with the application). With such changes, Dev CS is able to recognize project files and runs build process. Change in the project file:
Development process is centralized around pushing your local changes to Dev CS Git repository branch (this can be done directly from JDeveloper):
In this example, I commit my local changes into fixbugs branch, later changes can be merged into master branch through Dev CS UI:
Build. To merge changes in Dev CS into master branch, we need to register merge request. In the wizard you can specify Git repository name, target branch and review branch (the one from where we are going to get changes and apply to master branch):
You can specify approvers and later when changes are approved, they are merged to master branch.
Next step is build automation (this can invoked on demand or automatically). You can associate build process to Git branch and review past build results:
If you are building with Ant, make sure to add build.properties and build.xml files into ADF application (described in Shay's video). Here is example of build.properties file I'm using in the sample app for ADF 12.2.1.1/12.2.1.2:
Example of build.xml file to run build automation in Dev CS for ADF 12.2.1.1/12.2.1.2:
At first build process was always returning success, even I there were compilation issues left in the code on purpose. In order to force build process to return failure when it should, you need to check "Archive the artifacts" option in Post Build section of build job configuration. This will force build process to produce EAR and if this fails (because of compilation issues), it marks build process failure:
Deploy. Dev CS knows how to deploy EAR into Java Cloud Service. This can be done on demand or automatically, when build is successfully completed. Configuration is simple and straightforward, you need to provide connection details to Java Cloud Service and it works - you can deploy or redeploy:
Application is successfully deployed to Java Cloud Service and visible in EM:
Besides all this, Dev CS offers Wiki's, issue tracking and bunch of other useful features for day to day work in development. So far no complaints, good job Oracle.
There are excellent video tutorials recorded by Shay Schmeltzer, I would not repeat here all the steps, will post only key steps in the process and few extra tips. Watch Shay's videos to get understanding how it works and how to configure Developer Cloud Service (UI was changed since then, but still all config steps are valid):
1. Using Oracle Developer Cloud Service for Git and code review with JDeveloper Applications
2. Oracle ADF Build Automation on the Oracle Developer Cloud Service
Download ADF 12.2.1.1/12.2.1.2 example configured with Ant scripts for build automation on Dev CS - ADFAltaApp.
JDeveloper/ADF version. When I run OJDeploy build in Dev CS (Developer Cloud Service), I can see in the log it prints version 12.2.1.1. This means currently Dev CS supports ADF up to 12.2.1.1:
Locally I prefer working on 12.2.1.2, since JDeveloper is more stable in 12.2.1.2. When I was trying to build code commited from 12.2.12, Dev CS complained it can't open project file. I have solved it by changing 12.2.1.2 to 12.2.1.1 in *.jws and *.jpr files (luckily my local JDeveloper 12.2.1.2 doesn't complain about it and continues to work with the application). With such changes, Dev CS is able to recognize project files and runs build process. Change in the project file:
Development process is centralized around pushing your local changes to Dev CS Git repository branch (this can be done directly from JDeveloper):
In this example, I commit my local changes into fixbugs branch, later changes can be merged into master branch through Dev CS UI:
Build. To merge changes in Dev CS into master branch, we need to register merge request. In the wizard you can specify Git repository name, target branch and review branch (the one from where we are going to get changes and apply to master branch):
You can specify approvers and later when changes are approved, they are merged to master branch.
Next step is build automation (this can invoked on demand or automatically). You can associate build process to Git branch and review past build results:
If you are building with Ant, make sure to add build.properties and build.xml files into ADF application (described in Shay's video). Here is example of build.properties file I'm using in the sample app for ADF 12.2.1.1/12.2.1.2:
Example of build.xml file to run build automation in Dev CS for ADF 12.2.1.1/12.2.1.2:
At first build process was always returning success, even I there were compilation issues left in the code on purpose. In order to force build process to return failure when it should, you need to check "Archive the artifacts" option in Post Build section of build job configuration. This will force build process to produce EAR and if this fails (because of compilation issues), it marks build process failure:
Deploy. Dev CS knows how to deploy EAR into Java Cloud Service. This can be done on demand or automatically, when build is successfully completed. Configuration is simple and straightforward, you need to provide connection details to Java Cloud Service and it works - you can deploy or redeploy:
Application is successfully deployed to Java Cloud Service and visible in EM:
Besides all this, Dev CS offers Wiki's, issue tracking and bunch of other useful features for day to day work in development. So far no complaints, good job Oracle.
No comments:
Post a Comment