Today, I observed an exchange inside of Oracle about a topic that comes up from time to time. And it has to do with the development of APEX applications, and how you manage this across releases and a larger number of developers. This topic tends to vex some teams when they start working with Oracle Application Express on broader development projects, especially when people are not accustomed to a hosted declarative development model. I thought Koen Lostrie of Oracle Curriculum Development provided a brilliant response, and it was worth sharing with the broader APEX community.
Alec from Oracle asked:
"Are there any online resources that discuss how to work with APEX with multiple developers and multiple branches of development for an application? Our team is using Mercurial to do source control management now.
The basic workflow is that there are several developers who are working on mostly independent features. There are production, staging, development, and personal versions of the application code. Developers implement bug fixes or new features and those get pushed to the development version. Certain features from development get approved to go to staging and pushed. Those features in staging may be rolled back or promoted to go on to production. Are there resources which talk about implementing such a workflow using APEX? Or APEX instructors to talk to about this workflow?"
And to which I thought Koen gave a very clear reply, complete with evidence of how they are successfully managing this today in their Oracle Curriculum Development team. Koen said:
"I think a lot of teams struggle with what you are describing because of the nature of APEX source code and Database-based development. I personally think that the development flow should be adapted to APEX rather than trying to use an existing process and apply that for APEX.
Let me explain how we do it in our team:
- We release patches to production every 3 weeks. We have development/build/stage and production and use continuous integration to apply patches on build and stage.
- We use an Agile-based process. At the start of each cycle we determine what goes in the patch.
- Source control is done on Oracle Developer Cloud Service (ODCS) – we use git and source tree. We don’t branch.
- All developers work directly on development (the master environment) for bugs/small enhancement requests. We use the BUILD OPTION feature of APEX to prevent certain functionality from being exposed in production. This is a great feature which allows developer to create new APEX components in development but the changes are not visible in the other environments.
- For big changes like prototypes, a developer can work on his own instance but this rarely happens. It is more common for a developer to work on a copy of the app to test something out. Once the change gets approved. it will go into development.
From what I see in the process you describe, the challenge in your process is that new changes get pulled back after they have made it to stage. This is a very expensive step. The developers need to roll back their changes to an earlier state which is a very time consuming process. And… very frustrating for the individual developer. Is this really necessary ? Can the changes not be reviewed when in development ? Because that is what is proposed in the Agile methodology: the developer talks directly to the person/team that requests the new feature and they review as early as on development. In our case stage is only for testing changes. We fix bugs when the app is in stage, but we don’t roll back features once they are in stage – worst case we can delay the patch entirely but that happens very rarely.
There is a good paper available by Rob Van Wijk. He describes how each developer works on his own instance but keeps his environment in sync with the master. In his case too, they’re working on a central master environment. The setup of such an environment is quite complex. You can find the paper here: http://rwijk.blogspot.com/2013/03/paper-professional-software-development.html"