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.

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

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.

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

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:

1. Create a temporary directory (createTempDirectory)
2. Copy a given file to this directory (copyGivenFile)
3. Show the contents of the file (showContents)
4. 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:

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

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

When editing one of the steps we are able to indicate ‘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

When looking at Execute – DEV – Deploy Application Artifacts – D (just launching it)

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]

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

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

Create a ‘Production’ instance of the deployment procedure

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

We change the name of the procedure to ‘PRD – Deploy Application Artifacts’ and navigate to the Procedure Steps tab

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]

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.

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.

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]

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