Its a follow-up to our last follow-up! In this podcast, Robert and I close the lid on lifecycle management with a focus on the newest CRM On Demand environment – CTE! And of course, if you missed Part 1, never fear, you can find it here.

Last time we kicked off a discussion about the environments Oracle provides for our customers. We got pretty far with Staging and Production. I think we did a pretty thorough job, but we didn’t quite finish. Today we’re going to talk about the OTHER environments and some approaches you can employ to manage all this stuff.

And by “all this stuff” you of course mean the critical task of lifecycle management. All right, let’s kick it off.

CTE

This is really cool – Customer Test Environments. Oracle now gives you a couple of sandbox environments at no extra charge. They have Leading and Trailing environments, which determines when these environments get upgraded to the next major release of Oracle CRM On Demand.

That is, a “Leading” environment will always be on the latest release and patch level and will be in front of the line when Oracle is scheduling the “rolling” release of upgrades.

Trailing is, well, the opposite of that.

These are multi-tenant environments with a limited number of active users allowed – up to 20. It’s completely separate from your Production environment, so you can play around a lot in these environments.

So is CTE is a copy of production? No, it’s a totally separate instance – there is no refreshing either direction. Really no relationship at all to your production instance.

The benefit of CTE is that it is maintained just like Production – so you don’t have the periodic outages for maintenance and such. And because it doesn’t get refreshed, you never lose your work!

Can I request a copy of production or staging in my CTE?  No. Well, technically yes – you can request it, but the answer is no. Sorry.

So what is it good for?

It’s GREAT for trying out just about anything – new configurations, role settings, data loads. Robert and I have both had customers that found this environment to be invaluable in determining of a particular configuration or customization would work for them before making major changes in Production.

And of course integration development and testing. And let’s not forget Training.

What is it NOT good for?

I think due to the fact that you have to apply your configurations manually to CTE means for some customers it may not be the best place for quick validation testing. Meaning if I’ve made some minor change to a web service and I want to validate it, I may be better off going to Staging – which may be a closer match to Production at any point in time.

Private CTE

 We should mention that there is a recent offering we call “Private CTE”. This is for single tenant or @ customers. The neat thing about this is that it is refreshed from production (like staging) up to six times a year (upon request, 30 days notice), with additional (billable) refreshes upon request.

This CTE isn’t free, though. It’ll cost you, and that’s on top of the cost of Single Tenancy.

Anything else?

That’s pretty much it. I guess it’s worth mentioning that some have, in the past, purchased additional instances in their production environment. This was very popular before we had a staging or CTE.

Right, I remember those days.  Now we’ve formalized it as “Co-Located CTE” for our Single Tenant customers who have a pod all to themselves – and the users in the additional instance(s) count against the total license count.  So if you have 1000 licenses, and 800 active in your production instance, you could spin up a clCTE with up to 200 user accounts!

Migrating between environments

So we’ve covered the available environments. Now there’s one more area we should talk about before we wrap up – how do these various environments interact with each other?

In a traditional on premise software implementation, you’ve probably got three distinct environments – maybe more. A development area for doing all your initial work and testing. A staging area for final white glove and compatibility testing, and then production. And each progresses to the next (dev to stage, stage to prod).

If you’ve been listening, you know that the only automated propagation of changes from one environment to another is when production is copied to Staging. So does that mean there is no way to move my configuration from one place to another?

This is where the Migration Tools come in to play. You can use these to move changes to and from these environments.

Here’s a typical approach.

  1. We set up production for initial launch – most of our work is done directly here because we aren’t impacting any live users.
  2. Once the setup is locked down, we use the migration tool to export all the setup information from Prod.
  3. We use the migration tool again to load up the configuration to one of our CTE environments. We use that environment to try out any changes we might be considering.
  4. We also take a slice of users and data from Production and move it to CTE.
  5. After a while, Staging goes through a normal refresh cycle. We can now use Staging as a place to quickly test integration changes and the like.

Keep in mind that today the migration tools do a lot, but don’t cover 100% of the configuration and settings. Workflow and Books of business, for example, aren’t included. So you’ll still have some manual work to do to bring the environment in sync with production.

In addition, you’ll need to figure out how much data you want in these environments. Staging will be a full reflection of production. In CTE, you can decide how much data you want to import to facilitate ongoing development or training. And it’s a great place to put your training data.

Wrap-Up

So hopefully we’ve exhausted this topic – for now! If you think we missed anything or have a question, how about leaving us a comment? We love comments!

Share and Enjoy:
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitter
  • StumbleUpon
  • Technorati

Comments are closed.