Introduction
More and more the fast moving and changing world urges us to upgrade applications with new features to keep track with user demand.
In order to support a way of working that allows for short build and delivery cycles (Agile) the ‘DevOps’ way of working is introduced in many IT departments nowadays. Architectures specifically setup to support this way of working include tools like Jenkins, Nolio, Git, Puppet etc.
Those of us using Oracle Enterprise Manager would want to include EM within the ‘DevOps’ architecture. Considering we want to use the EM deployment framework, a typical role for EM could be the role of Orchestrator.
I have written this article based on experiences I had while implementing a ‘DevOps’ way of working using EM on projects I was involved in.
Assumptions
In this article, I assume you have chosen for a single production environment for EM. What I mean by that is that you did not choose to create multiple EM environments to support development, test, acceptance (staging) and production.
Obviously, you should have a separate EM environment to test infrastructure changes like patching and upgrades.
Considerations
When using EM as part of your ‘DevOps’ architecture the following topics need to be considered:
- Security
- Development (Code and Build)
- Testing
- Deploy (Release)
Security
Development account
In order to centralize the management of code (creation and maintenance) we create a ‘Team’ dedicated account. This account will be what we call a NPA (Non personal account). Let’s say we have an Accounting team, we would create an administrator EM_DEV_ACCOUNTING. This administrator therefor would need EM_PROVISIONING_DESIGNER privileges. The Accounting team would become ‘owner’ of this account.

Team related development NPA administrators
Roles
Team members will be allowed to run deployment procedures based on their DevOps role. To support this, we will create a Developer and an Operator role. Team members will then be granted the proper role.
As part of the ‘Build’ we will grant access to deployment procedures by granting execution access to the Developer and Operator role.
In the example where we are developing deployment procedures for the Accounting team we would create roles:
- EM_RL_ACCOUNTING_DEVL
- EM_RL_ACCOUNTING_OPER

Developer and Operator roles
The Developer role than would have access to the Development and Test lifecycle targets only as would have the Operator to the Acceptance (Staging) and Production lifecycle targets.
Ideally you would have organized all of your targets based on its lifecycle stage.

Administration Group based on target lifecycle stage
Development
As mentioned earlier, we use a central Non-Personal Account for the development of our deployment procedures.
For instance, let’s use the EM_DEV_ACCOUNTING account to do the development of our deployment procedures. After we have setup this account and finished development of our procedure(s), tested, accepted and promoted to production, we will transfer the ownership of the account to the responsible team (in this example Accounting). This team will be responsible for setting and storing the password.
Processing changes
Whenever a change need to be made to any of the delivered procedures, a change request will be created and allow for distributing the password to the development team again. After completing the change request, the responsible team will reset the password again.
Using the Software Library
Most probably you will be creating directives to implement procedure step logic. To organize the software library to support multiple teams creating and using directives we will create folders per team.
Per folder access rights can be managed

Directives dedicated folders per team in the Software Library
Creating a custom Deployment Procedure
When starting to create a new Deployment Procedure we will be using naming conventions to distinguish between ‘development’ and ‘production’ images.
Let’s say we create a Deployment Procedure for the deployment of some application artifacts on an application server. In this case, we would create the procedure using the following naming convention:
DEV –
In our example this could be: DEV – Deploy application artifacts
Always use latest revision
While creating your procedure steps and relate them to directives (located in the software library), the best thing would be to use ‘always use latest revision’.
This would allow you to apply changes to your directive while developing and next perform test runs on your procedure without having to bother assigning the latest revision of your directive to the procedure step.
Example
Create a procedure (DEV – Deploy Application Artifacts) that:
- Create a temporary directory (createTempDirectory)
- Copy a given file to this directory (copyGivenFile)
- Show the contents of the file (showContents)
- Remove the temporary directory (cleanUp)
We create a procedure with 4 procedure steps using 4 directives
The directives we have created are located in the software library:

The Accounting owned directives in the Software Library
Notice the team dedicated folders to store directives.
Let’s take a closer look at the deployment procedure we have created: DEV – Deploy Application Artifacts

‘Development’ procedure
When opening the procedure (pressing [Edit Procedure Definition]) we get access to the specification like the procedure steps that are included…

The procedure steps as part of the procedure
When editing one of the steps we are able to indicate ‘Always Use Latest Revision’

Always Use Latest Revision
Testing your procedure
When testing the procedure, the most convenient way is to create a profile that includes some of your test input data.
You can create such a profile by launching the deployment procedure, enter your input (Deployment server and File name) and press [Save] instead of [Submit]. A profile now is created including the input your entered.
As we want to authorize the procedure to the proper DevOps roles we will create 4 profiles for each of the lifecycle stages:
Procedure profile | Target hosts |
Execute – DEV – Deploy Application Artifacts – D | Development |
Execute – DEV – Deploy Application Artifacts – T | Test |
Execute – DEV – Deploy Application Artifacts – A | Acceptance (Staging) |
Execute – DEV – Deploy Application Artifacts – P | Production |

Example environment consisting of D, T, A (Stage) and P server
When looking at Execute – DEV – Deploy Application Artifacts – D (just launching it)

Deployment procedure Profile
It includes myserver1 as ‘Default’ deployment server, a ‘Development’ lifecycle target.
Best practice would be to include each target in a dynamic group (Administration Group), so that you can authorize all ‘Accounting – Development’ and ‘Accounting – Test’ targets to the EM_RL_ACCOUNTING_DEVL role and all ‘Accounting – Acceptance’ and ‘Accounting – Production’ targets to the EM_RL_ACCOUNTING_OPER role.
Through this, a user launching the example profile could choose to include other hosts as deployment server, but would always be restricted to ‘Development’ and ‘Test’ hosts.
Authorize the profiles to the proper DevOps roles
Last step would be to authorize each of the profile to the proper DevOps role, as shown in the following example:
Select the profile and select ‘Edit Permissions’ from the list and press [Go]

Granting authorization to the Accounting Operator role
By using the [Add] button we have selected the ‘Developer’ role for the Accounting team and authorized ‘View’ privilege to allow all Accounting team members assigned the ‘Developer’ role to execute this profile on ‘Development’ and ‘Test’ targets only.
Promoting to Production
After testing of the deployment procedure completed successfully, you would want to promote the procedure to production.
For this we will perform the following:
Indicate ‘Production’ maturity for each of the directives
After creation of a directive, the directive will have ‘Untested’ as maturity

Untested directives
After successfully testing we want to change to ‘Production’ maturity.

Production revision of directives
Create a ‘Production’ instance of the deployment procedure
Using the [Create like] button we create a copy of the ‘DEV’ deployment procedure

Create Production procedure version using [Create Like]

Editing the procedure steps
What we need to do next is: make sure that for every procedure step, you deselect the ‘Always User Latest Revision’ indicator.
This would be the only guarantee that any future changes in any of the directives will not impact the current ‘Production’ procedure.
Downside of this approach obviously is the fact that if any of the directives is changed, you need to make sure the ‘Production’ procedure uses the proper revision in its associated procedure step.
After opening the procedure step ([Edit]) press [Next]

Deselect the Always Use Latest Revision indicator
Here you would select ‘Select New Directive’, make sure you have selected the proper directive revision and deselect the ‘Always Use Latest Revision’ indicator and press [Next] to complete the procedure step definition.

Production Deployment Procedure
Now we have a ‘Production’ version of the deployment procedure.
For this ‘Production’ version of the deployment procedure we would create 4 profiles, like we did for the ‘Test’ version.

Procedure profiles
Authorization
As discussed for the ‘Development’ version of the deployment procedure we need to authorize the ‘Production’ version as well, by selecting the profile, select ‘Edit permissions’ and press [Go]

Authorizing the Operator role
The example above shows the authorization of the deployment procedure for ‘Accounting Production’ targets to the ‘Operator’ role