Build Options & Agile Development

Build Options are a really powerful feature of APEX that gives developers a lot of flexibility, especially when doing Agile development. They allow you to control the contents of an application that is displayed at run-time. As an Agile APEX developer, what do you do as the current sprint is winding down and some developers need to start moving on to the contents of the next sprint in order to keep busy? You don’t want your developers sitting idle, but you can’t create a release for the current sprint until all the work is done - and you also can’t release Sprint 1 if it contains unfinished Sprint 2 content. As long as your sprint contents can be easily separated, i.e. you aren’t reworking the same component in each sprint; the simple solution is to create build options that correspond to your sprints. By consistently assigning the build options to the components you develop during a sprint, you create an easy mechanism to ‘turn off’ parts of the application at run-time. Developers can work on both Sprint 1 and Sprint 2 contents simultaneously, and when the application is exported for the Sprint 1 release, you can effectively set all Sprint 2 content to be excluded. When the Sprint 1 application is installed in another environment and a user runs the application, they will be none-the-wiser that any Sprint 2 contents has been developed.

Build Options can be found under Shared Components in the Security section. When you create a build option you have a couple of choices. First, you will have to give it a name. If doing Agile development, I name them after the sprints using Sprint 1, Sprint 2, etc.



Next, you will need to chose the Status. You have two options, Include or Exclude. This status will be set for the current environment. Choose Include if, when you run the application, you would like to see the features that correspond to this build option. Choose Exclude if, when you run the application, you want to hide the features that correspond to this build option. Keep in mind this only excludes the feature from being shown at run-time; you will still be able to see the components in the page designer. I set this to Include as I like to be able to see the changes I am making to the application when I run it in development.

Now, you will need to decide on the Default on Export status. This option determines if the build option will be included or excluded when the application is exported. This feature is key for working with sprints. I set the current sprint and all prior sprints to Include. All future sprints should be set to Exclude, this ensures that when the application is exported and imported in to a new environment only the contents of the finished sprints are visible to the end-user.



Maybe the most important step is to assign the build options as you develop. You can set the Build Option in the Configuration section of a component and you can assign them to pretty much any component: pages, page items, computations, validations, dynamic actions, page processes… the list goes on. If you need to check the status of build options within PL/SQL code, take a look at this article by Martin Giffy D’Souza or if that isn’t enough control, there is always conditional compilation of the database schema as described by Jeff Kemp.



Once all of your build options are assigned and your sprints have the proper Include/Export status - you are all set. If you ever want to test what the application will look like with a certain Build Option excluded, simply switch the Status for that build option to Exclude and run the application.

You can even take things a step further and document the application components belonging to each sprint/build option by querying the data dictionary. This query can be turned into a report that can then be printed (with APEX Office Print, of course) and included in your sprint release notes.

- Jackie -