Attendees to this year’s ODTUG Kscope conference had the opportunity to get involved in a live software development experience on the Red Gate exhibition stand. The entire stand was turned into a mini development lab to create a prototype for a new tool which will make it easier to put your schemas under version control.

Over the course of the 3 exhibition days we ran a series of rapid feedback sessions and developed the prototype as we learned what Oracle developers and DBAs required: features were added, deleted and improved. We left the show with a pretty good idea on how the new tool will help Oracle teams automate the process of pushing database changes into source control, and provide visibility across the team of any changes to the database and whether they are in sync with source control.

Day 1 – Monday June 25, 2012

We kicked day 1 off with a stand up meeting to make sure we were prepared for the first set of feedback sessions, which coincided with the morning coffee breaks.

In one UX session we sat down with two guys who were developers on the same team. One guy explained how he spent all of his time in the IDE and needed some kind of context menu integration to get started using the tool. We had an interesting discussion about the level of notification required; one of them wanted to be notified of how many outstanding items he had to commit, the other didn’t as he only committed changes every few days. Both agreed that they liked the idea of being able to see what other team members were committing in real time.

We also had some really useful feedback about the set-up wizard for linking a database to your source control repository and the type of configuration options that might be required. We’ve introduced a step in the wizard to allow users to choose which schemas to add to their source control repository. That’s because people told us that they wouldn’t want some of the standard Oracle schemas to be put into source control, so they need an option to exclude them.

From talking to several people here at Kscope it’s clear that Release Managers, Team Managers and DBAs could also benefit from using the tool, not just Oracle database developers. For example, a Manager or DBA might want to see all changes that have been made, who made them, when they made them, why they made them and if they remembered to put their changes into source control or not. One participant in a UX session drew us a diagram of his organisation’s set-up to explain how they had more than 200 schemas to monitor.

On Tuesday we’ll be making some changes to the paper prototype and getting more feedback. Here is some of the feedback we had today:

Day 2 – Tuesday June 26, 2012

On day 2 the stand was very busy and we ran UX sessions with customers throughout the day. One of the main bits of feedback we had was that people would like a way to filter objects on the ‘Commit’ screen. The Commit screen will show you objects that have been changed in your local (or development) database, but are different to the latest version in source control. People we spoke to told us that they wanted to be able to sort objects or alternatively filter them by a text string, e.g. an object name prefix such as ‘APP’.

We had a couple of very useful sessions where we talked through a typical development and release process, which helped us to understand the context and ‘pain points’ that different organisations experience currently with their databases and source control. For example, we spoke to a lady who said her organisation was source controlling their databases using Subversion. All database developers in her organisation are meant to check out objects from Subversion before they work on them. However, typically a developer may get distracted by a phone call, or an urgent support query, and forgets to check in the object they have been working on. Source Control for Oracle will help provide visibility of database changes that have not yet been committed (or checked in) to source control, by providing an up to the minute comparison between database objects and latest version in source control.

Another important feature we added to our prototype, based on feedback from Kscope attendees, was a field to add a Subversion tag when committing database changes, so that you can tie a change set to a particular release. A DBA may want to check out any objects with a particular Subversion tag when updating a production database as part of a release.

The revised paper prototype of the Commit screen (shown below) demonstrates how we integrated the feature to add a Subversion tag, as well as a keyword filter and sorting on columns.

Commit screen paper prototype for Source Control for Oracle

As the day progressed we also gathered a lot more feedback on what IDE’s people are using and what source control systems they use. At the moment PLSQL Developer and SQL Developer seem to be winning on the IDE front, and Subversion is by far the most popular source control system.

The most popular IDE is PLSQL Developer and the most popular Source Control system is Subversion

Day 3 – Wednesday June 27, 2012

We got lots of great feedback on day 2 and worked hard to move the suggestions from paper prototype to the HTML prototype. David had a late-night coding session to add sorting and filtering to the commit tab, which lots of people had a go with on the stand today. Cary Millsap, Dominic Delmolino, Alex Gorbachev and Ron Crisco came by the stand first thing for a UX session with Michele and Martin Giffy D’Souza interviewed me for ODTUG. It was really encouraging to have people come back to the stand on the last day to see the progress we had made during the conference.

The final day provided an opportunity to explore more design ideas. For example, how to provide different views of information in the history screen to filter and sort database objects. One great idea from the session with Cary, Dominic and Ron, was to introduce an object level search and timeline of changes made to that object.

A very interesting observation by Cary was that if Oracle development teams do not have the ability to work efficiently and effectively by source controlling their databases, it can affect the type of applications they are able to work on.

Some of the sessions helped build up more detail and context around the kind of problems that affect database developers. In one session we discussed the issues that occur when different remote development teams work on maintaining the same application. Remote teams have a greater need to be kept aware of what database objects their colleagues are changing and whether the objects have been checked back into source control since changes were made. Maintaining awareness across teams is critical.

We are returning home with lots of invaluable feedback from the Oracle community who have attended Kscope. Next week we will complete our Agile process with review and retrospective meetings, to summarise the lessons we learnt about the Live Lab experiment!

We now need your help as we create the application

We believe collaboration drives quality, which is why we want you to be involved right through the development of the new tool – creating the prototype with Kscope12 attendees was just the start!

Please visit: to see how you can help.