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"
I've read Rob van Wijk's excellent white paper. In fact, I had it on my desk at one point when I first mulled over how to best version an APEX application. It's the closest thing to an effective APEX version control and distributed development strategy I've seen. The team I am working with has adopted a repository structure similar to the one in the paper (splitting out APEX objects into dedicated files), but still utilizes a single development environment for multiple developers. The problem that we have struggled with (and in my mind the biggest obstacle to version controlling APEX properly) is the merging of APEX pages. Rob's article covers this, but the team here couldn't be convinced to attempt merging of APEX pages in a distributed set-up.
ReplyDeleteWe have tried to adopt an iterative approach to development in a shared APEX environment and basically it doesn't work. Without separate development environments, developers can not work independently on the same areas of the application without stepping on each others toes. One developer locking down a page whilst he makes his changes is not conducive to Agile and iterative development.
It would be interesting to hear from other Agile APEX developers about how they have adopted an iterative approach to development. Do you have a single development environment or distributed? If distributed, do you merge APEX pages? If you are using a single development environment, then what is the purpose of your continuous integration process and how does it work? How do you iteratively develop a single page by working on several user stories split across multiple developers?
For me, these are the biggest challenges I have faced as an APEX developer working on a large application with several developers.