Version Control of APEX Pages and Shared Components

Question

Background:
My organisation has a large customer base and over the last 2 years we have migrating from a forms to an apex user presentation layer. We have had a number of customers live on the apex front end for close to a year now.
Our current method of releasing apex objects is at the application level (ie applications are exported for version control in PVCS and then released to Test etc). We now want to investigate exporting pages and shared components individually. Hence, I have a few questions:
1. If I export a page and this is checked into PVCS and I forget to export a 'List of Values' shared component. What happens when the page in PVCS is created in another environment (ie Test). I guess the ‘Page Import’ would still succeed but the reference to the ‘List of Values’ would be some large made up number.
How would we detect the missing dependency after import ?
2. Regarding New or Changed Templates. Once again, if a page references a new template and is then exported, checked into PVCS and imported into test but the template is missed for migration to test, would the import succeed but the template reference would be broken, like in number 1.
3. How can Application level objects be locked (reserved) when undergoing modification.
Any comments would be appreciated especially if there are any sites using pages and shared component exports for version control and releases.
For anyone who's interested, the method we are thinking of using is:
..Page Export script will be version controlled
..ALL the shared component export scripts will be added to 1 main SQL script
Hence we only end up with 2 configurable objects in PVCS.

Answer 1

Nigel,
1. If I export a page and this is checked into PVCS and I forget to export a 'List of Values' shared component. What happens when the page in PVCS is created in another environment (ie Test). I guess the ‘Page Import’ would still succeed but the reference to the ‘List of Values’ would be some large made up number.
For component export/import, the source and target worskpace ID and application ID must be identical. You can achieve the workspace "sameness" by exporting and importing the workspace from one database to another, thus preserving the workspace's numeric ID, aka security group ID. Similarly applications must be exported/imported/installed without changing their IDs in the installed-into instance. More fundamentally, the application you import/install components into must be an identical copy of the source application with respect to the internal object IDs, allowing only for differences that incent you to migrate changes from a higher rev level of the application into a copy that is at a lower rev level.
As to the specific question, if you copied a page but didn't copy an LOV into the target application then if the LOV referenced by the page already existed in the target application then page would simply reference the existing, perhaps down-level, LOV in the application. If the LOV did not already exist but had been newly created in the source application, then the target application page would contain an invalid reference and would produce a runtime error.
How would we detect the missing dependency after import ?
I don't know of any reports that would tell you this. There are several types of omissions that you need to watch out for, not all of which can be detected by inspection of the target application in isolation.
2. Regarding New or Changed Templates. Once again, if a page references a new template and is then exported, checked into PVCS and imported into test but the template is missed for migration to test, would the import succeed but the template reference would be broken, like in number 1.
Yes, same case.
3. How can Application level objects be locked (reserved) when undergoing modification.
There is no provision for this as there is for pages.
For anyone who's interested, the method we are thinking of using is:
..Page Export script will be version controlled
..ALL the shared component export scripts will be added to 1 main SQL script
Hence we only end up with 2 configurable objects in PVCS.
So you propose to have one script of all pages and another script for everything else? I'm not sure I got that right.
Scott