In this follow-up to our discussion of good Governance, Robert and Louis expound upon the topic of Lifecycle Management, with a focus on the environments Oracle CRM On Demand makes available for development, testing and training. There is a lot to talk about, so we’ve split this into two exciting podcasts.

One area we touched on in our last post was understanding Oracle maintenance schedules – which leads to a bigger discussion of what environments are available and what you can, or should, do with them. 

Let me set the stage with a nightmare scenario. For the last two months you’ve been building a complex integration and set of configurations in preparation for roll-out. You’ve been loading data, configuring pages and building web services against your staging environment. Halfway through testing, you log-in one morning to staging and find that all your test data and configurations are gone! You’ve just been punked!

 Well, not exactly punked  – you’ve been refreshed. And if you were paying attention, you’d have seen the alerts telling you it was coming. So if Staging isn’t the right place for this kind of development and testing, what is? 

Let’s take a look at each of the different CRM On Demand environments and the advantages and gotchas of each.


We’ve already mentioned this one, so let’s dig a bit deeper. All customers have a staging environment – sometimes this has been referred to as a development environment.  Oracle Stage is essentially a copy of your Production environment on a different set of hardware. Oracle Operations and Engineering use it to test out certain things prior to promoting to production.

So the “staging” is really for Oracle, not for the customer, eh? We apply patches and upgrades there pretty regularly as part of regular maintenance. It is refreshed quarterly, meaning that every 90 days or so, Operations takes a copy of your Production environment and pastes it into the Oracle Stage environment, wiping out anything that was there. That includes all configurations and your data.

It’s no charge for the customer to access it, but it is an Oracle environment. This means that there is absolutely no SLA on it, and Oracle reserves the right to do things to it with minimal notice.

Generally you can rely on the “Service Information” link to tell you what is happening there, but the key point here is that while it’s available for you to play with, it may not be available when you need it.

So what is Staging good for?

I think one of the most important roles Staging plays is testing upgrades. Don’t worry, we do a heckuva lot of testing before it goes there, so we rarely uncover major bugs.   We give all customers an opportunity to log in to staging a few weeks ahead of a major production upgrade so they can test their customizations, configurations, reports, whatever. During that period we ask them to log SRs for any issues so they get special attention. Keep in mind the testing is optional and the exact test plans are up to the customer.

OK, upgrade testing makes sense  – what about development in Staging?

As with many things On Demand, it depends. If your development timeline fell within two of the refreshes, it is a decent place to implement configuration changes, test and then document the changes to be copied in the Production Environment. Good thing to emphasize here – there isn’t a magic button to press that moves all of the changes from Oracle Stage to your Production environment, so documenting any changes made there is key.

We know many customers and partners use the Staging environment for lots of development activities – testing a web service, assessing new configurations or visibility settings, trying out data loads. All fine and good as long as you know the timing for refreshes, and can handle the occasional unplanned maintenance outage.

So what is Staging NOT good for?

How about Training? We get asked that a lot and generally we aren’t too fond of the idea. Because staging has variable up-time and gets overwritten periodically, it often conflicts with set training schedules. As we’ll discuss later, there may better options.

Performance testing is another. While staging can give you a general idea of what to expect in production, it’s not really going to be a reliable representation.


But I thought we were talking about development, testing and training environments? Isn’t doing that in Production a no-no?

Sometimes! Actually, before we had Staging, all we had was production. And that worked fine for most. Here’s one area that is very different from a typical on premise deployment. Most of the initial development can – and should – occur in production. Because there is no “promotion” of changes in a dev environment to prod, it really makes the most sense to do your development directly in Production.

But what about possibly screwing up data? Or making changes that are hard to back out? Well, you should be cautious about data, but there aren’t many things you can do in OD that can’t be undone or cleaned up or hidden from users. Custom fields is a good example – if you find that you don’t need a field you added early in your configuration, you can just rename it with a “zz” in front (this pushed it to the bottom of the list) and remove it from all page layouts. This will have zero impact on users.

Again, this only applies to a system that isn’t yet live. But the fact is that doing all your initial development in a separate environment has very little benefit.

So how could you use production for ongoing development?

The key is to weigh the potential for impact on live users. So testing a web service that might update or delete thousands of records – not a good idea. Even a web service that doesn’t touch data may tie up resources and hurt general performance (if poorly written), so this is a good candidate for Staging.

But perhaps you want to create a new role with a different set of privileges or access. You can easily create a new role – assign new page layouts and such to it – and try it out in Production without impairing data or affecting anyone’s experience.

Right – so minor testing and development is OK in prod. Sounds like the point is to really carefully consider how any change might impact live users and live data.

Other Stuff?

This is where we get to Part 2, which you’ll just have a wait a little while for! We’ll continue the conversation by talking about our recently introduced Customer Test Environments (CTEs), and the tools available to migrate changes from one environment to another.


For me, the key takeaway is that you just can’t approach Saas lifecycle management the way you do on premise software. Being aware of the environments available to you and the advantages / gotchas of each can help you plan your lifecycle strategy.

Share and Enjoy:
  • Digg
  • LinkedIn
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitter
  • StumbleUpon
  • Technorati

Comments are closed.