7 Replies Latest reply: Nov 16, 2011 1:42 PM by tillie RSS

    Development to Production / Migration questions

    User720285-Oracle
      I have a few questions that relate to migrations from a development instance to production, and keeping the environments in sync.

      BACKGROUND INFO
      As a "side" project at my place of employment I have created an APEX app that is being used and has been very well received. Since it went well, they have now asked for a 2nd larger application and have assigned a 2nd person to work with me on this. The other person is gung-ho that we need to develop in a development instance and then migrate to production when we are ready to go live so we have been working this way. At this point, we have 2 totally separate APEX workspaces, lets call them DEV and PROD for now. This sounds great on paper, but I have experienced a few challenges.

      MY QUESTIONS
      1. Lets say we log into DEV and make a few minor changes to a single page. There does not seem to be a way to migrate just the one single page or its changes into PROD. It seems the only way would be to migrate the entire app over again, which seems silly if we only made 1 or 2 small changes.

      2. Assuming the answer to question #1 is NO (in other words every little change requires migrating the entire app), then how can I avoid the URL changing after each migration?

      3. It seems when migrating over DB schema objects (tables, views, procedures, etc..) APEX generates a massive script for you broken into ndividual sub-scripts separated by a slash. However, it also seems that you can't simply run the entire massive script at once, but must run each individual sub-script one at a time. Is there a quicker way?

      4. Is there an easy way to migrate over any scheduled jobs I created with DBMS_SCHEDULER?

      5. At this point, DEV and PROD are rather out of sync, so I would like to essentially start over and erase DEV and then rebuild it by simply making a copy of PROD (if this is possible). In other words I'm looking for any info on how to create a refresh process. Mind you, I don't have actual DBA access (only access is via the APEX web interface) so is there an easy way to clone one APEX workspace into another without DBA privileges?

      6. I assume the answer to #5 is NO. Assuming this, is there a quick way to basically erase everything in APEX workspace, and then I can manually start migrating objects from PROD in?

      Any tips/suggestions/recommendations are appreciated.

      Thank you,

      Paul
        • 1. Re: Development to Production / Migration questions
          TexasApexDeveloper
          Welcome to the forum.. I will try to answer your questions in order..

          user720285 wrote:
          I have a few questions that relate to migrations from a development instance to production, and keeping the environments in sync.

          BACKGROUND INFO
          As a "side" project at my place of employment I have created an APEX app that is being used and has been very well received. Since it went well, they have now asked for a 2nd larger application and have assigned a 2nd person to work with me on this. The other person is gung-ho that we need to develop in a development instance and then migrate to production when we are ready to go live so we have been working this way. At this point, we have 2 totally separate APEX workspaces, lets call them DEV and PROD for now. This sounds great on paper, but I have experienced a few challenges.

          MY QUESTIONS
          1. Lets say we log into DEV and make a few minor changes to a single page. There does not seem to be a way to migrate just the one single page or its changes into PROD. It seems the only way would be to migrate the entire app over again, which seems silly if we only made 1 or 2 small changes.
          If your apps BOTH have the same APP ID, you can export pages from development and import them into your production application, via the import/export mechanism in APEX. However, you MUST keep the app id's in sync.

          >
          2. Assuming the answer to question #1 is NO (in other words every little change requires migrating the entire app), then how can I avoid the URL changing after each migration?
          Refer to answer given in #1.. Also, you can use an application alias, so that if you DO change the app id, the url should NOT change, since you are using the alias as apposed to App id in url string.

          >
          3. It seems when migrating over DB schema objects (tables, views, procedures, etc..) APEX generates a massive script for you broken into ndividual sub-scripts separated by a slash. However, it also seems that you can't simply run the entire massive script at once, but must run each individual sub-script one at a time. Is there a quicker way?
          What I recommend, is to bundle the ddl code as part of the install script, under supporting objects in your application, thus the code can be run in it's entirety when you do an install of your application.
          >
          4. Is there an easy way to migrate over any scheduled jobs I created with DBMS_SCHEDULER?
          I would bundle this in the install code of your application, as noted above. Since it is just a pl/sql script to submit your dbms_scheduler job<s>, it makes sense to do it this way in a script with ddl objects building.
          >
          5. At this point, DEV and PROD are rather out of sync, so I would like to essentially start over and erase DEV and then rebuild it by simply making a copy of PROD (if this is possible). In other words I'm looking for any info on how to create a refresh process. Mind you, I don't have actual DBA access (only access is via the APEX web interface) so is there an easy way to clone one APEX workspace into another without DBA privileges?
          If you are serious about wanting to wipe development out, there are scripts about that will allow you to wipe ALL database objects from a schema, and then you would delete the applications in development. Then you could just export your application and database objects and data from production and import them in development.

          For the database data I would use sql developer to build insert scripts and load them into the supporting objects section of application with the ddl to Build the objects..

          >
          6. I assume the answer to #5 is NO. Assuming this, is there a quick way to basically erase everything in APEX workspace, and then I can manually start migrating objects from PROD in?

          Any tips/suggestions/recommendations are appreciated.

          Thank you,

          Paul
          Thank you,

          Tony Miller
          Raleigh, NC
          • 2. Re: Development to Production / Migration questions
            Joel_C
            TexasApexDeveloper wrote:
            Welcome to the forum.. I will try to answer your questions in order..

            user720285 wrote:
            I have a few questions that relate to migrations from a development instance to production, and keeping the environments in sync.

            BACKGROUND INFO
            As a "side" project at my place of employment I have created an APEX app that is being used and has been very well received. Since it went well, they have now asked for a 2nd larger application and have assigned a 2nd person to work with me on this. The other person is gung-ho that we need to develop in a development instance and then migrate to production when we are ready to go live so we have been working this way. At this point, we have 2 totally separate APEX workspaces, lets call them DEV and PROD for now. This sounds great on paper, but I have experienced a few challenges.

            MY QUESTIONS
            1. Lets say we log into DEV and make a few minor changes to a single page. There does not seem to be a way to migrate just the one single page or its changes into PROD. It seems the only way would be to migrate the entire app over again, which seems silly if we only made 1 or 2 small changes.
            If your apps BOTH have the same APP ID, you can export pages from development and import them into your production application, via the import/export mechanism in APEX. However, you MUST keep the app id's in sync.
            He says above that these are separate workspaces, not necessarily on separate apex instances (perhaps stretching the definition of "completely separate" I would concede). If that were the case, surely you can only have unique APP_IDs? In which case, your suggestion doesn't make sense. What I would say is that you can over-write applications when you install, thus re-using the application ID (if necessary). As such, it isn't necessary for the "URL" to change (by which he means "app_id", I assume?). I would concur that making use of application aliases is best practice.
            3. It seems when migrating over DB schema objects (tables, views, procedures, etc..) APEX generates a massive script for you broken into ndividual sub-scripts separated by a slash. However, it also seems that you can't simply run the entire massive script at once, but must run each individual sub-script one at a time. Is there a quicker way?
            What I recommend, is to bundle the ddl code as part of the install script, under supporting objects in your application, thus the code can be run in it's entirety when you do an install of your application.
            I think this is a fine approach where you are completely replacing an application with a new one - it's a more complicated situation if you are merely making amendments to an existing app, where it might not be appropriate to wipe out tables and re-create them, particularly if you have to make adjustments to data in the process.

            There is an option for creating upgrade scripts vs. complete installation and I would follow this approach (See the documentation for more details: http://download.oracle.com/docs/cd/E23903_01/doc/doc.41/e21674/deployment.htm#BABJEBCB). Creating the appropriate scripts is a bit more involved than a fresh install - I would recommend taking a look at the "Database Diff" options in SQL Developer (http://www.oracle.com/technetwork/developer-tools/sql-developer/sqldev31-newfeatures-486949.html), although there are other "Schema Comparison" solutions out there.
            • 3. Re: Development to Production / Migration questions
              User720285-Oracle
              Thanks for both of your replies.

              It will not let me create an application with the same ID in the other workspace, presumably because they are hosted on the same APEX server. Even though the workpaces are unique, I suppose the app IDs must be unique across all workspaces in the DB.

              I wonder if there is a workaround on this one?

              Thanks
              • 4. Re: Development to Production / Migration questions
                Joel_C
                Yes, application IDs are unique to the APEX instance, precluding you from using it for different applications. The only 'workaround' to this would be to ensure you never hardcode the app ID into your code (bearing in mind hardcoding of any kind is generally to be avoided, where possible) - use the :APP_ID item instead. In addition, you can use an application alias - this only needs to be unique within a workspace (although that workspace must then be specified in the URL as well if there are 'conflicts'). See the relevant parts of the documentation for more details:

                http://download.oracle.com/docs/cd/E23903_01/doc/doc.41/e21674/bldr_attr.htm#sthref566

                http://download.oracle.com/docs/cd/E23903_01/doc/doc.41/e21674/concept_url.htm#HTMDB03020

                I would question the importance of retaining the same ID between your "DEV" and "PROD" applications - the value of the ID in and of itself has no real meaning outside of providing a pointer to a particular application. For example, if your application is 'live' and you're working on the development version, how would you propose to differentiate between the two if they somehow had the same ID? I think you are making more problems for yourself than you need to in being concerned about this - bear in mind that you can over-write one application's ID with another during the installation process (if you are concerned about retaining the existing 'live' ID).

                If you haven't done so already, I'd really recommend reading the "Deploying an Application" chapter of the documentation - it discusses the various options open to you and (I think) demystifies the process somewhat:

                http://download.oracle.com/docs/cd/E23903_01/doc/doc.41/e21674/deploy.htm
                • 5. Re: Development to Production / Migration questions
                  Haakon
                  Hi,

                  I have the same "challenge" - trying to migrate single page changes from development to production environment.
                  I've tried going through the "Packaged Application" sections, but quickly get lost as to how one is to "package" a single page.... this part of Apex i a bit of a maze - at least to me....

                  So I decided to go by the more logical export-import way.

                  I've made sure that my application- & page IDs are the same in both environments, and then did the following:

                  - from the Page Designer, selected "Utilities | Export"
                  - "Export Page" : made sure the File Format was DOS
                  - exported the page to an sql file (f<appid>page<pageid>.sql)
                  - then switched to the production environment and selected Import in the Application Builder
                  - selected the exported file and let Apex process it
                  - selected to "Install Page" in the last step of the import wizard
                  - confirmed that I wanted to replace the existing page with the imported one, and everything went well.

                  This enables me to distribute page changes at least from development to production environment.

                  Regards,
                  -Haakon-
                  • 6. Re: Development to Production / Migration questions
                    tillie
                    I am going thru the same process as Haakon, but when it comes time to install the page I get the following error:
                    This page was exported from a different application or from an application in different workspace. Page cannot be installed in this application.

                    Different instances of APEX with the same App Ids and same Workspace ID's. Don't understand why this process doesn't work for my app.
                    • 7. Re: Development to Production / Migration questions
                      tillie
                      found problem with my workspace id's. When we upgraded the database somehow the workspace Id got changed. Have to find out from DBA how that happened, but I fear I know.