7 Replies Latest reply: Jul 12, 2012 11:40 PM by Luis Cabral RSS

    The dance of the IDs

    Luis Cabral
      Hello,

      We use Apex 4.0.1 and (to simplify) say we have 2 environments: DEV and PROD (both with same workspace ID.)

      Application 10 is in production, and currently being modified in DEV as part of an improvement project.

      However a bug is found in PROD and needs to be fixed as soon as possible. The steps we take are:

      - Get the version currently in PROD from CVS
      - Import it under a different application ID in the DEV environment, say application 11.
      - Fix the bug

      Now the problem starts. We always deploy whole applications to other environments (rather than individual components) and we want to keep the same application ID when we deploy this fix to PROD. But we only have the run-time environment in PROD, so it is not possible to override the application ID during deployment. So what we do is:

      - Export DEV application 10 (the one being modified)
      - Export DEV application 11 (the one with the bug fix)
      - Import DEV application 11 over application 10
      - Export DEV application 10 (the one with the bug fix)
      - Import DEV applicaton 10 back (the one being modified)
      - Deploy DEV application 10 to PROD (the one with the bug fix)

      Is there a way to improve this (other than manually modifying the application ID in the export file)?

      Another problem we have is that, once application 10 is imported into application 11, all the internal IDs change (hence the title of this post. :) ) This makes comparing versions in CVS a nightmare. Any way to prevent it? The only way seems to be import the application from PROD into the same application number in DEV, but this has an impact in the development process as no new development can be done until the bug is fixed.

      Thanks
      Luis
        • 1. Re: The dance of the IDs
          Luis Cabral
          No comments on this? No-one ever faced this issue or have any advice on how to minimise the impact of this?

          Source control is very important in any development project, and in special in large and complex projects and / or with big development teams. Not being able to identify what was changed by a developer in a specific CVS version (rather than what was changed as a result of importing an application under a different ID) is quite serious I think.

          It seems that Apex applications are tightly tied to the ID under which they reside in the metadata layer. However I think this shouldn't be like that, after all it is the same application, with the same pages and same logic even if I import it under a different ID. Bounding each application forever to the ID it was originally created under is seems a bit restrictive to me.

          If there are no workarounds for this at the moment, maybe this could be improved somehow in the future?

          Thanks
          Luis
          • 2. Re: The dance of the IDs
            mobra
            But we only have the run-time environment in PROD, so it is not possible to override the application ID during deployment.
            Have you seen this?

            http://joelkallman.blogspot.no/2010/07/apexapplicationinstall.html

            http://docs.oracle.com/cd/E17556_01/doc/apirefs.40/e15519/apex_app_inst.htm


            - Morten

            http://ora-00001.blogspot.com
            • 3. Re: The dance of the IDs
              Luis Cabral
              Thanks Morten. This definitely helps with one of the issues.

              Interestingly enough, in the very same blog post someone asks something related to the other problem we are having. He asks about multiple developers working on the same application and trying to consolidate their work using CVS but having problem with the ever changing IDs:
              Using generate_offset during import works great, but has a disadvantage that each developer's export, after an export split, contains new ID's, making each version totally different from the version under version control.
              Same problem here in a slightly different scenario!

              Our scenario here is much, much simpler. We don't have multiple workspaces and developers working independently. We simply need to patch the application version which in in production without impacting the work on the version in the development environment. Do we need a full separate environment (database + Apex) for something so simple like that in order to keep the IDs in sync?

              Cheers
              Luis
              • 4. Re: The dance of the IDs
                jozef_SVK
                Hi,

                I normal use two env's DEV and PROD as you.
                There are the applications with the same ID's on both env's (there is no problem with any dance of ID's).

                About your problem:
                Luis Cabral wrote:The only way seems to be import the application from PROD into the same application number in DEV, but this has an impact in the development process as no new development can be done until the bug is fixed.
                Do you want to do a new development on the version without fix the bug ? How is it possible (the bug will be there or no ?) ?

                Regards
                J :D
                • 5. Re: The dance of the IDs
                  Luis Cabral
                  Hello,
                  jozef_SVK wrote:
                  I normal use two env's DEV and PROD as you.
                  There are the applications with the same ID's on both env's (there is no problem with any dance of ID's).
                  I have explained the problem in my original post but I am happy to explain it again (hopefully in a more clear way this time) because I find this very important.

                  1 - Application X is in production (PROD) and normal, improvement work is currently being done in the development environment (DEV).
                  2 - A bug is found in PROD that needs to be fixed as quick as possible. The current version of the application in DEV is being worked on and obviously cannot be deployed to PROD for the purpose of fixing that bug.
                  3 - Hence, the version in PROD needs to be imported in DEV under a different ID than the original one so the bug can be fixed. This messes up all the IDs and CVS is almost useless.
                  Do you want to do a new development on the version without fix the bug ? How is it possible (the bug will be there or no ?) ?
                  Obviously the bug will be fixed in the DEV version as well as part of the new development, but as explained above the fix cannot wait for the current work there to finish to be deployed to PROD.

                  I think this is quite a common scenario in the software development world.

                  Cheers
                  Luis
                  • 6. Re: The dance of the IDs
                    jozef_SVK
                    Hi,

                    1) You could try to export actual DEV version of the application for example 100.
                    2) Import it back into DEV env but with different ID (e.g. 101) - development can continues on app 101.

                    3) Export app 100 from PROD -> Import it into DEV as 100 (replace the one in DEV) -> Fix The bug -> Export it from DEV (100) -> Import it to PROD (still ID = 100)
                    4) Export 101 from DEV and import it back to DEV as 100

                    Maybe it will help :) (if you didnt develop some new functions and use the ID of the application in some script like '100' instead of :APP_ID)

                    Regards
                    J :D
                    • 7. Re: The dance of the IDs
                      Luis Cabral
                      Thanks Jozef, but the problem still does not seem to be clear to you.
                      jozef_SVK wrote:
                      1) You could try to export actual DEV version of the application for example 100.
                      2) Import it back into DEV env but with different ID (e.g. 101) - development can continues on app 101.
                      If this is done, all the internal IDs (not only the application ID itself) of the DEV version will change, which defeats the purpose of doing this.
                      4) Export 101 from DEV and import it back to DEV as 100
                      When it is imported back into app number 100 they will change once again! Internal IDs change every time you import an app under a different ID. Not very helpful from a CVS perspective.

                      Cheers
                      Luis