Best practices for Test - Production promotions

Good Day to all
Environment:
OWB Client: 10.1.0.2.0 on Windows XP Professional
OWB Server Side: 10.1.0.2.0 on UNIX (AIX 5.2)
Repository: Oracle 9.2.0.4 on UNIX (AIX 5.2)
Runtime Schema: Oracle 9.2.0.4 on UNIX (AIX 5.2)
I am trying to put together an idiot-proof process to have our Infrastructure Team (Operators) facilitate the promotion of OWB objects from our Test environment to our Production environment.
The Production environment is a separate OWB Repository and separate target schema.
Thanks to SOX we can't have one person be able to update both environments.
I am thinking of using UNIX scripts to run MDL Exports and MDL Imports and OMBPLUS to do the deployments.
Has anyone implemented such a process?
My other thought was to use the 'Deploy to File' method and OMBPLUS to do the actual deployment.
Any pros and cons to either method?
Any and all opinions are most welcomed.
Many thanks.
Gary

Upon further research it appears I'll need a combination of exp/imp and OMBPlus to do what I need. Please correct any of the below assumptions:
1 - I need to use exp/imp to get the object definitions from the Test repository to Production repository.
2 - I need to do a 'Deploy to File' through the OWB Client on the Test repository objects to generate the deployment files.
3 - I then need to use OMBPlus to deploy the objects on the Production side.
Questions:
1 - Is there a way to get the 'Deploy to File' output in a command line environment so it can be scripted in UNIX?
2 - Is there a way to set up a 'Deploy Only' type user so the Operators can ONLY deploy objects and NOT change anything?
Thanks very much for the help. I'm very interested in how other companies are handling the separation of duties with SOX and these moves from Test to Production.
Till then...
Gary

Similar Messages

Best practices for development / production environments

Our current scenario:
We have one production database server containing the APEX development install, plus all production data.
We have one development server that is cloned nightly (via RMAN duplicate) from production. It therefore also contains a full APEX development environment, and all our production data, albeit 1 day old.
Our desired scenario:
We want to convert the production database to a runtime only environment.
We want to be able to develop in the test environment, but since this is an RMAN duplicated database, every night the runtime APEX will overlay it, and the production versions of the apps will overlay. However, we still want to have up to date data against which to develop.
Questions: What is best practice for this sort of thing? We've considered a couple options:
1.) Find a way to clone the database (RMAN or something else), that will leave the existing APEX environment intact? If such is doable, we can modify our nightly refresh procedure to refresh the data, but not APEX.
2.) Move apex (in both prod and dev environments) to a separate database containing only APEX, and use DBLINKS to point to the data in both cases. The nightly refresh would only refresh the data and the APEX database would be unaffected. This would require rewriting all apps to use DBLINKS though, as well as requiring a change to the code when moving to production (i.e. modify the DBLINK to the production value)
3.) Require the developers to export their apps when done for the day, and reimport the following morning. This would leave the RMAN duplication process unchanged, and would add a manual step which the developers loath.
We basically have two mutually exclusive requirements - refresh the database nightly for the sake of fresh data, but don't refresh the database ever for the sake of the APEX environment.
Again, any suggestions on best practices would be helpful.
Thanks,
Bill Johnson

Bill,
To clarify, you do have the ability to export/import, happily, at the application level. The issue is that if you have an application that consist of more than a couple of pages, you will find yourself in a situation where changes to page 3 are tested and ready but, changes to pages 2, 5 and 6 are still in various stages of development. You will need to get the change for page 5 in to resolve a critical production issue. How do you do this without sending pages 2, 5 and 6 in their current state if you have to move the application all at once??? The issue is that you absolutely are going to need to version control at the page level, not at the application level.
Moreover, the only supported way of exporting items is via the GUI. While practically everyone doing serious APEX development has gone on to either PL/SQL or Utility hacks, Oracle still will not release a supported method for doing this. I have no idea why this would be...maybe one of the developers would care to comment on the matter. Obviously, if you want to automate, you will have to accept this caveat.
As to which version of the backend source control tool you use, the short answer is that it really doesn't matter. As far as the VC system is concerned, you APEX exports are simply files. Some versioning systems allow promotion of code through various SDLC stages. I am not sure about GIT in particular but, if it doesn't support this directly, you could always mimic the behavior with multiple repositories. Taht is, create a development repository into which you automatically update via exports every night. Whenever particular changes are promoted to production, you can at that time export form the development repository and into the production. You could, of course, create as many of these "stops" as necessary to mirror your shop's SDLC stages, e.g. dev, qa, intergation, staging, production etc.
-Joe
Edited by: Joe Upshaw on Feb 5, 2013 10:31 AM

Best practice for test reports location -multiple installers

Hi,
What is recommended best practice for saving test reports with multiple installers of different applications:
For example, if I have 3 different teststand installers: Installer1, Installer2 and Installer3 and I want to save test reports of each installer at:
1. C:\Reports\Installer1\TestReportfilename
2. C:\Reports\Installer2\TestReportfilename
3. C:\Reports\Installer3\TestReportfilename
How could I do this programatically as to have all reports at the proper folder when teststand installers are deployed to a test PC?
Thanks,
Frank

There's no recommended best practice for what you're suggesting. The example here shows how to programmatically modify a report path. And, this Knowledge Base describes how you can change a report's filepath based on test results.
-Mike
Applications Engineer
National Instuments

Best practice for test to production

I actually only have one server for test and production, but the dev processes all point to development databases and the production processes will point to production databases.
The only real change is to make the JMS queue points to prod vs test. There doesn't seem to be an easy way to copy a complete process and change the name. That would work best for me.
Any ideas?
Edited by: ss396s on Nov 19, 2009 9:21 AM

Yes you can. With SOA 11g, you can create deployment profiles to change poperties during deployment. You can also build your own deployment mechanism, as I did.
http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html
Marc

Best Practices for APO Production Support

What are the best practices needs to be adopt for APO Production Support? in DP, SNP, PP/DS, CIF, APO-basis, APO -ABAP area?

I know this is not the standard way to reach you, but you answered a question long back about /SAPAPO/AMON1 - Alert Monitor. Can this alert monitor be configured to show up in the universal worklist (UWL) in the portal? if so would these alerts show up in the alert inbox of the uwl just as other sap alerts do? (the other alerts i speak of are those referenced here (http://help.sap.com/saphelp_nw04s/helpdata/en/3f/81023cfa699508e10000000a11402f/frameset.htm).
Or are these alerts two totally different types of functionality with the same name (ARERT) ?
Thanks
Ted Smith

Best practice for testing a web form after converting to a connection file

I was using InfoPath to test a web form using a web service for the connection. I decided to deploy the form to SharePoint to make sure it worked outside of InfoPath preview mode. This required me to convert the connection to a connection file and publish
that in SharePoint. After getting all that set up, it appears to work from SharePoint.
Now I want to go back and work on the form some more. But in InfoPath it appears preview is no longer an option because the form is using a connection file. While trying to preview the form I am given a message that basically says the form will have to be
published in order for it to make the connection. This would mean I would have to overwrite the form on SharePoint just to test.
I suppose I could publish to a different form library and switch back when I'm done but it would seem that InfoPath preview should still be an option for testing. Is there something I'm missing in InfoPath that would allow me to still test with this form?

Not sure what you're doing, but previewing IP forms with data connections should be quite possible.
Scott Brickey
MCTS, MCPD, MCITP
www.sbrickey.com
Strategic Data Systems - for all your SharePoint needs
To put it simply, here are the basic steps:
Create IP form based on web service
Fill out form and test via Preview
Convert data connection to a connection file
Publish IP form and test on SharePoint
Go back into IP and try to test again via Preview <--- no longer works - now stuck with testing on SharePoint which is "live"
This could be a factor of how our SharePoint environment is configured. I have no other experience to base it on.

Best practice for adding products in multiple languages

We have multiple products with the same product number and product name - but have different descriptions (translations).
Our BigMachines quotation system allows us to have several language layers for the same product. But it seems like this is not possible in CRMOD?
I guess the work around would be to have x amount of fields containing the description in different languages in CRMOD.
Just wanted to confirm this before moving on down that road..
Regards,
Allan

Thank's Bobb. That was unfortunately the answer I expected.
I can't really wait for the enhancement, so I thought of the following work around:
- Rename the product name field to product number
- Create x amout of new product name and product description fields (for each language)
Do you see any pitfalls here?
Regards,
Allan

Best Practice for Production environment

Hello everyone,
can someone share the best practice for a production environment? or is there a SAP standard best practice to follow in a Production landscape?
i understand there are Best practices available for Implementation , Migration and upgrade. But, i was unable to find one for productive landscape
thanks.

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

Best practices for promotions to production

My company's production environment is way to lose, I need to implement some controls. My analysts keep fouling up the production objects. Does anyone know of best practices for an organization rolling out production changes?
thanks

Yes you can. With SOA 11g, you can create deployment profiles to change poperties during deployment. You can also build your own deployment mechanism, as I did.
http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html
Marc

Best practice for a deplomyent (EAR containing WAR/EJB) in a productive environment

Hi there,
I'm looking for some hints regarding to the best practice deployment in a productive
environment (currently we are not using a WLS-cluster);
We are using ANT for buildung, packaging and (dynamic) deployment (via weblogic.Deployer)
on the development environment and this works fine (in the meantime);
For my point of view, I would like to prefere this kind of Deploment not only
for the development, also for the productive system.
But I found some hints in some books, and this guys prefere the static deployment
for the p-system.
My question now:
Could anybody provide me with some links to some whitepapers regarding best practice
for a deployment into a p-system ??
What is your experiance with the new two-phase-deploment coming up with WLS 7.0
Is it really a good idea to use the static deployment (what is the advantage of
this kind of deployment ???
THX in advanced
-Martin

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

Best practice for the test environment & DBA plan Activities Documents

Dears,,
In our company, we made sizing for hardware.
we have Three environments ( Test/Development , Training , Production ).
But, the test environment servers less than Production environment servers.
My question is:
How to make the best practice for the test environment?
( Is there any recommendations from Oracle related to this , any PDF files help me ............ )
Also please , Can I have a detail document regarding the DBA plan activities?
I appreciate your help and advise
Thanks
Edited by: user4520487 on Mar 3, 2009 11:08 PM

Follow your build document for the same steps you used to build production.
You should know where all your code is. You can use the deployment manager to export your configurations. Export customized files from MDS. Just follow the process again, and you will have a clean instance not containing production data.
It only takes a lot of time if your client is lacking documentation or if you re not familiar with all the parts of the environment. What's 2-3 hours compared to all the issues you will run into if you copy databases or import/export schemas?
-Kevin

Best Practice for Production IDM setup

Hi, what is the best practice for setting up prodcution IDM:
1. Connect IDM prod to ECC DEV,QA and Prod or
2. Connect IDM prod to ECC prod only and Connect IDM dev to ECC Dev and QA.
Please also specify pros and cons for both options if possible.
Thanks in advance,
Farhan

We run our IDM installation as per your option 2 (Prod and non-prod on separate instances)
We use HCM for the source of truth in production and have a strict policy regarding not allowing non HCM based user accounts. HCM creates the SU01 record and details are downloaded to IDM through the LDAP extract. Access is provision based on Roles attached to the HCM Position in IDM. In Dev/test/uat we create user logins in IDM and push the details out.
Our thinking was that we definitely needed a testing environment for development and patch testing, and it needs to be separate to production. It was also ideal to use this second environment for dev/test/uat since we are in the middle of a major SAP project rollout and are creating hundreds of test and training users with various roles and prefer to keep this out of a production instance.
Lately we also created a sandpit environment since I found that I could not do destructive testing or development in the dev/test/uat instance because we were becoming reliant on this environment being available. Almost a second production instance - since we also set the policy that all changes are made through IDM and no direct SU01 changes are permitted.
Have a close look at your usage requirements before deciding which structure works best for you.

Best practice for promoting roles

I would like to know what is the best practices for promoting Administrative and/or normal Roles between environments. If I make a change to the capabilities of a role, I'd rather not create a whole new build if I didn't have to. Would exporting from debug, and importing via 'lh import' suffice, or is there an easier/better method?
Thanks

Hello,
I'd ask in the Windows forum on Microsoft Community.
Karl
When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer.
My Blog:http://unlockpowershell.wordpress.com
My Book:Windows PowerShell 2.0 Bible
My E-mail: -join ('6F6C646B61726C40686F746D61696C2E636F6D'-split'(?<=\G.{2})'|%{if($_){[char][int]"0x$_"}})

Best practice for EBS Testing

Hello Friends - We are doing EBS Configuration and it includes Search strings also. These changes are applicable to around 40-50 Bank accounts.
Is it that I should ask Bank to send us test Bank statements for all these accounts.
Can you pls share Best practices to test EBS set up.
Thanks

Hello!
You don't have to test EBS for each bank account. The best approach to testing is to identify the typical bank statement cases and test them. For instance, if you have bank statements from five banks with several bank accounts in each bank, you need to test the one bank statement for one bank account from each bank. Similarly, if you have different types of bank accounts (e.g. current account, deposit account, transfer account etc.), you will have different operation types in bank statements for these accounts. Therefore, you also have to test bank statement from different account types.
To sum up, test typical bank statements from each bank and different bank statements from each account type if applicable.
Hope this will help you!
Best regards!

Best Practices for Staging

Hey Guys!
We are currently evaluating Oracle Enterprise Pack for Eclipse with one of our new projects.
As we are moving from development phase to QA, we are looking for ways to standardize the staging process. Up to now we were unable to figure out how or where OEPE creates the artifacts (war & ear files) before they are deployed to the remote target environment (Weblogic Server) for tests during development. We had assumed that OEPE uses a simple ANT file or something similar we could use for our staging environments.
Is there a Best Practice for Staging? What does Oracle recommend?
Thanks in advance - Alex

Hi,
According to your post, my understanding is that you wanted to know the best practices to deploy SharePoint Portal in different SharePoint environment.
If the site is not existing in the production server, we can save the site from the development server, and then import it to the production server.
But if the site is already existing in the production server, we should follow these steps to just add the taxonomy and content types to the production server:
Save the site from Dev as a template
Import the template as solution in Visual Studio
Remove unnecessary items from the solution(Please pay more attention on it. If a content type/list... in the solution is existing in the production site too, it will replace the
same object existing in the production after deployment)
Package the solution
Deploy the solution in the production
For more detailed, please see:
http://ahmedmadany.wordpress.com/2012/12/30/importing-sharepoint-solution-package-wsp-into-visual-studio-2010/
There is a similar thread for your reference.
http://social.technet.microsoft.com/Forums/en-US/7dcf61a8-1af2-4f83-a04c-ff6c439e8268/best-practices-guide-for-deploying-sharepoint-2010-from-dev-to-test-to-production?forum=sharepointgeneralprevious
Thanks & Regards,
Jason
Jason Guo
TechNet Community Support

Best practices for Test - Production promotions

Similar Messages

Maybe you are looking for