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

Similar Messages

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 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 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

Best practices for a development/production scenario with ORACLE PORTAL 10G

Hi all,
we'd like to know what is the best approach for maintaining a dual development/production portal scenario. Specially important is the process of moving from dev. to prod. and what it implies in terms of portal availability in the production environment.
I suppose the best policy to achieve this is to have two portal instances and move content via transport sets. Am I right? Is there any specific documentation about dev/prod scenarios? Can anybody help with some experiences? We are a little afraid regarding transport sets, as we have heard some horror stories about them...
Thanks in advance and have a nice day.

It would be ok for a pair of pages and a template.
I meant transport sets failed for moving an entire pagegroup (about 100 pages, 1Gb of documents).
But if your need only deals with a few pages, I therefore would direclty developp on the production system : make a copy of the page, work on it, then change links.
Regards

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 deploying in Production Cluster

          I have the following.
          2 Physical machines each running 2 jvm's, thus I have 4 jvm's in my cluster.
          We access the jvm's via an IIS plug-in.
          When it comes time to do a new .war file migration, do you need to stop the jvm's
          first ?
          I have tried deploying with the jvm's live, it technically worked but we then
          noticed several 404 errors during the day on a servlet that was there. (Called
          successfully around the 404)
          Anyway, I'm just looking for recomendations on how others deploy to production.
          Tim


          Tim wrote:
          > I have the following.
          >
          > 2 Physical machines each running 2 jvm's, thus I have 4 jvm's in my cluster.
          >
          > We access the jvm's via an IIS plug-in.
          >
          > When it comes time to do a new .war file migration, do you need to stop the jvm's
          > first ?
          You should be able to redeploy a web application without any
          problems? When you get this 404 errors, do you see any stacktrace
          on the server window
          Kumar
          >
          >
          > I have tried deploying with the jvm's live, it technically worked but we then
          > noticed several 404 errors during the day on a servlet that was there. (Called
          > successfully around the 404)
          >
          > Anyway, I'm just looking for recomendations on how others deploy to production.
          >
          > Tim

Best practices for setting up projects

We recently adopted using Captivate for our WBT modules.
As a former Flash and Director user, I can say it’s
fast and does some great things. Doesn’t play so nice with
others on different occasions, but I’m learning. This forum
has been a great source for search and read on specific topics.
I’m trying to understand best practices for using this
product. We’ve had some problems with file size and
incorporating audio and video into our projects. Fortunately, the
forum has helped a lot with that. What I haven’t found a lot
of information on is good or better ways to set up individual
files, use multiple files and publish projects. We’ve decided
to go the route of putting standalones on our Intranet. My gut says
yuck, but for our situation I have yet to find a better way.
My question for discussion, then is: what are some best
practices for setting up individual files, using multiple files and
publishing projects? Any references or input on this would be
appreciated.

Hi,
Here are some of my suggestions:
1) Set up a style guide for all your standard slides. Eg.
Title slide, Index slide, chapter slide, end slide, screen capture,
non-screen capture, quizzes etc. This makes life a lot easier.
2) Create your own buttons and captions. The standard ones
are pretty ordinary, and it's hard to get a slick looking style
happening with the standard captions. They are pretty easy to
create (search for add print button to learn how to create
buttons). There should instructions on how to customise captions
somewhere on this forum. Customising means that you can also use
words, symbols, colours unique to your organisation.
3) Google elearning providers. Most use captivate and will
allow you to open samples or temporarily view selected modules.
This will give you great insight on what not to do and some good
ideas on what works well.
4) Timings: Using the above research, I got others to
complete the sample modules to get a feel for timings. The results
were clear, 10 mins good, 15 mins okay, 20 mins kind of okay, 30
mins bad, bad, bad. It's truly better to have a learner complete
2-3 short modules in 30 mins than one big monster. The other
benefit is that shorter files equal smaller size.
5) Narration: It's best to narrate each slide individually
(particularly for screen capture slides). You are more likely to
get it right on the first take, it's easier to edit and you don't
have to re-record the whole thing if you need to update it in
future. To get a slicker effect, use at least two voices: one male,
one female and use slightly different accents.
6) Screen capture slides: If you are recording filling out
long window based databse pages where the compulsory fields are
marked (eg. with a red asterisk) - you don't need to show how to
fill out every field. It's much easier for the learner (and you) to
show how to fill out the first few fields, then fade the screen
capture out, fade the end of the form in with the instructions on
what to do next. This will reduce your file size. In one of my
forms, this meant the removal of about 18 slides!
7) Auto captions: they are verbose (eg. 'Click on Print
Button' instead of 'Click Print'; 'Select the Print Preview item'
instead of 'Select Print Preview'). You have to edit them.
8) PC training syntax: Buttons and hyperlinks should normally
be 'click'; selections from drop down boxes or file lists are
normally 'select': Captivate sometimes mixes them up. Instructions
should always be written in the correct order: eg. Good: Click
'File', Select 'Print Preview'; Bad: Select 'Print Preview' from
the 'File Menu'. Button names, hyperlinks, selections are normally
written in bold
9) Instruction syntax: should always be written in an active
voice: eg. 'Click Options to open the printer menu' instead of
'When the Options button is clicked on, the printer menu will open'
10) Break all modules into chapters. Frame each chapter with
a chapter slide. It's also a good idea to show the Index page
before each chapter slide with a progress indicator (I use an
animated arrow to flash next to the name of the next chapter), I
use a start button rather a 'next' button for the start of each
chapter. You should always have a module overview with the purpose
of the course and a summary slide which states what was covered and
they have complete the module.
11) Put a transparent click button somewhere on each slide.
Set the properties of the click box to take the learner back to the
start of the current chapter by pressing F2. This allows them to
jump back to the start of their chapter at any time. You can also
do a similar thing on the index pages which jumps them to another
chapter.
12) Recording video capture: best to do it at normal speed
and be concious of where your mouse is. Minimise your clicks. Most
people (until they start working with captivate) are sloppy with
their mouse and you end up with lots of unnecessarily slides that
you have to delete out. The speed will default to how you recorded
it and this will reduce the amount of time you spend on changing
timings.
13) Captions: My rule of thumb is minimum of 4 seconds - and
longer depending on the amount of words. Eg. Click 'Print Preview'
is 4 seconds, a paragraph is longer. If you creating knowledge
based modules, make the timing long (eg. 2-3 minutes) and put in a
next button so that the learner can click when they are ready.
Also, narration means the slides will normally be slightly longer.
14) Be creative: Capitvate is desk bound. There are some
learners that just don't respond no matter how interactive
Captivate can be. Incorporate non-captivate and desk free
activities. Eg. As part of our OHS module, there is an activity
where the learner has to print off the floor plan, and then wander
around the floor marking on th emap key items such as: fire exits;
first aid kit, broom and mop cupboard, stationary cupboard, etc.
Good luck!

Tips n Tricks/Best Practices for integrating iPhone, iPad and MacBook Pro

My wife just purchased an iPhone, iPad and Macbook Pro for her non profit consulting business and I was wondering if a tips and tricks or best practices for efficiently and productively integrating these devices exists?

http://www.apple.com/icloud/

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 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 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 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 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 practice for test to production

Similar Messages

Maybe you are looking for