This content has been marked as final. Show 13 replies
Take a look at this to show how to automate your version c ontrol with APEX and SUBVERSION...
Since APEX can have applications exported as one pl/sql file, version control can be done easily, with communication within your development group..
this talks about exporting apex objects and use that to control the version but this would not work in a real world applications I think.
Example: I have a simple emp applications with 2 pages besides the login and main page. 1st app page is an interactive report and 2nd one is the f/m.
The interactive page has 10 revisions/versions and f/m can have 20. if you want to make a cutoff and say you want to send up to version 8 for the interactive report and only version 10 for the f/m to your QA environment, how would you do it?
This would only work if you would create a backup of each object that you change every time which if true would require a lot of work. Basically 1 backup script per page? you can have 1000 pages and each page can be changed multiple times a day and if you have been using this for a year that means gaziilion backup and that is assuming a back is created for each version otherwise you can be missing some.
I'm looking for a better real world methodology.
I hope I'm making some sense on my issue.
APEX stores an app internally as metadata, so you don't have 10 changes with 10 versions of code, you have the latest change.. So if you have 3 developers modifying stuff you need to COORDINATE the changes to pages and objects...
When you EXPORT an application to version control, you need to coordinate changes to a version.. We try to do nightly version control of our apps, just to be sane...
A blonde goes to the doctor and as she touches each part of her body with her finger she says: Doc it hurts everywhere. My leg hurts, my arm hurts, my neck hurts, and even my head hurts! Doc what's wrong? The doctor answers: Your finger is broken!
You are making terrific sense, Apex is not only not-version control friendly, but makes version control an almost impossible task.
I am also looking for a better way but I am almost convinced that there is none. Apex 4.2 has lots of new functionalities but as far as I know nothing was done to improve integration with revision control systems. It is like they don't care about it, which is frustrating because revision control is extremely important for any system of some complexity. I say this as a constructive criticism.
We have a hard time here controlling versions of Apex applications. The methodology we use is that an Apex application is a unit. We don't control the versions of individual pages or other objects. We try to promote whole applications across environments whenever possible, by coordinating efforts among developers. If for any reason, for example, we need to deploy change A in page 10 to QA but not change B in page 20, we either:
- Undo the changes in page 20 and export the app, then apply the changes again
- Manually edit the export file to remove the undesired change
(at this point someone could say, just promote page 10; but this is a simple example, in most cases dozens of changes are made to an application across multiple pages, including shared objects, and only a handful should not be promoted)
This is terrible, terrible, prone to errors and time-consuming, but I don't see any other way of doing it.
And this is a simple scenario, there are other much complex scenarios. I also would like to hear from other people how they manage this.
Thanks for you input and I think most of the people who does APEX is doing simple web application whereas we are dealing with complex ERP but we are still evaluating APEX and this is one area that gives me the biggest concern. We have several systems that at first i'm thinking of create 1 app for all due to a session issue across multiple apps but due to this version limitation would it be better to have multiple apps instead of 1 so it would be easier to update the other environments.
If you are using a custom authentication and have your own user tables can you still tell APEX that to use the same session across multiple apps?
Thanks in advance.
Hello. I have similar problems/questions about APEX and version control. I have come to the same conclusion that Luis did--keep the APEX application as a unit, manually make changes in multiple branches, etc. It seems parallel development is very difficult to accomplish.
For example, we have version 1.xx fielded, 2.xx in final test, and 3.xx starting development. If a bug was found in 1.xx, how can we not have to manually make the same change in the other branches? Or if a late feature is added to 2.xx (after 3.xx has branched), how can we merge the isolated changes in 3.xx? I've tried the APEXExport and APEXExportSplitter command line tools. It looked promising, however, all the export IDs from each of the development environments are different. So instead of 1 file with a lot of ID changes, we have hundreds of files with a few changes in each. If the split files could be merged for only the page changes, or shared components, etc, then we would be able to handle the APEX source similar to all our other source in configuration management.
How can we easily manage/merge changes among different branches? Is anyone trying to use APEX in a parallel development environment? Oracle has added a lot of agile/team capabilities, but maintenance is becoming difficult.
Interesting thread, we also consider an APEX application as an unit but as described by others it comes with a lot of downsides.
Yes you can share a session accross multiple apps (search for Session Cookie) so if you can design your product with multiple modules (APEX applications) this would be better.
Another good practice would be to put all your PL/SQL code in packages and only call your functions and procedures in APEX, it would be easier to maintain and control.
We are current using Oracle forms and we have about 500 forms and each form has 1 to 30 pages of screens. If I make this as 1 APEX app and consider this as 1 unit for version control I think its going to be nightmare since at any point in time there are several developers working and if we need to send something for us to undo all changes and put it back is almost impossible especially the way APEX works. Also at the same time we need to support our clients and each client can have different versions of the app.
Is it best to try to split this into as many apps? What if you create 1 app for each form then the version control would be easier but what would be the drawback?
I'm sure you are thinking of doing a pilot once you settle on an approach. Something not too small -- big enough to be real-world -- but not too big. Maybe 20 to 50 forms in a couple of related applications -- not just isolated forms -- not just apps with only 1 form. Perhaps some forms you use for in-house testing / monitoring / maintenance rather than something mission-critical. But then, if it isn't mission-critical, you won't see any/all the problems associated with mission-critical apps. will you? Just thinking out loud here.
I'm with everybody that asks for better source control. I dearly like apex, but when the topic comes to version control there is not much to say. In my opinion better source control should be given to us by apex out of the box. We have great exporting options and all, but we really need to be able to handle things more granularly. I'm rather glad that so far i've been the single developer on all apps. Some of the larger ones would be a nightmare to keep track of if even 3 were working away at it, and the app should get to production with fixes. Yikes.
There is probably a reason why threads about versioning keep popping up now and again, with the same questions and half-solutions each time.
It's probably a good idea to unite over this, and not let it wax and wane. On the apex feature request application there is a subversion feature request "Integrate with Subversion". And it's not even top spot, standing at a score of 4.8/5, with even one vote for "not desirable - not needed, I'd like to see the Oracle team do more important requests".
I'm not sure if someone who voted like that ever had to work with multiple people on a project, but then again i could be wrong.
You all have an account and you can all log on, and if this is something you deem worthy of your time, go there and add a vote and maybe a comment. I don't believe that adding posts here now and again about subversioning will ever help. Maybe the feature request gets ignored, who knows, but i'd say it has a better chance to be seen.
http://apex.oracle.com/pls/apex/f?p=55447 , look for the "Integrate with Subversion" request. And no, this is not my feature request, but im happy it got made :-)
It's probably a good idea to unite over this, and not let it wax and wane. On the apex feature request application there is a subversion feature request "Integrate with Subversion". And it's not even top spot, standing at a score of 4.8/5, with even one vote for "not desirable - not needed, I'd like to see the Oracle team do more important requests".This only shows what most people say about Apex -- that it is a tool for small, departmental and non-critical applications. If I only use Apex to create a 2-page application to "replace an excel spreadsheet", I'd be more interested on fancy themes and other bells and whistles to make my app look pretty, not hard core team development features or version control integration.
However, the product management needs to be smarter than this and although it is not a "top request" it needs to realise that it is of high importance for Apex to progress further in the enterprise-wide, critical applications area.
But to you see this happening? Everyone knows that Apex is a direct competitor of ADF, and oracle itself pushes ADF as the preferred tool for enterprise-wide apps. At least that is the impression I have.
One option would be to create an open source Apex clone so the community could do the improvements that are really necessary :)
SAID THAT, even with all these unresolved issues, developing and deploying apps with Apex is still 10x+ faster than with ADF
Good point, just voted for the feature request, people thinking this is an essential feature for APEX future should do the same!