RoundhousE is an automated database deployment and change management system. We started to use it over a year ago, so it’s time for an experience report.

At the current moment we’re using RoundhousE in 3 big projects and 5 smaller ones each deploying new versions and schema updates at least once a month in an automated way to over 25 on-site client installations. And it’s working great!

This year 2 more big projects are planned to start using RoundhousE for database migrations. And each new project that starts, small or big has to use RoundhousE. It has become a company policy.

Developer and integration sandboxes

We provide each project with development sandboxes on the developers machine and a project integration sandbox on the build server. The project databases get rebuild from scratch with every automated build using the MsBuild integration of RoundhousE. Database migration scripts are getting tested over and over on different platforms (sql server 2005/2008 and oracle 10/11).

Deploy into a copy of production

We’ve set up an internal production like environment where new versions are pushed upon and tested first, before being released to production.

We integrated the execution of the RoundhousE console in a self made PowerShell script, that also updates the version of the application (stopping/starting services and websites, copying binaries that kind of stuff).

Deploy into production

Because we have those environments mentioned above, and the deployment is already tested, a production migration rarely fails. And even if it fails on Sql Server, that’s not a big issue, because RoundhousE runs the migration in a transaction. So nothing happened.

Conventions around RoundhousE

We implied 3 conventions to make the process run smoothly:

Before we start deploying with RoundhousE on a project, the current databases in production need to have the exact same schema. This is also the hardest part in our process, but once it’s completed it’s a gift from heaven. :-)

Only the database user which RoundhousE uses to perform the migration has the right to make schema updates to the database. And the development team does not know those credentials. That way we assure that only RoundhousE performs schema updates.

Nothing gets deployed into production before it’s deployed to our internal environment.

To make it perfect

The Oracle integration still needs some work, so maybe a real Oracle expert can contribute to the project, enlightening us with the wonderful internals of Oracle.

The agile movement is happening for about 10 years now. A growing number of people and teams pick up the agile principles, methods and practices.

And no one would ever want to go back to the 'old' days. Agile becoming mainstream is definitively a good thing!

From time to time I hear people say that they work in an Agile Company. But what does that even mean?

Does it mean that everyone in your company knows and uses the agile lingua?
Or that you're doing iterative development with sprint planning and review meetings?
That teams continuously learn through retrospectives?
Or that you're applying continuous delivery, pair programming, test/behavior driven development,...?
Or that you’re applying Customer Development?
Or practice Lean and Kanban practices?
Or that your Scrum Masters and Product Owners are certified?
Or all of the above?

Let's take a step back and try to reflect a set of questions on the 4 agile values stated on the well known VersionOne Agile Poster: adaptability, transparency, simplicity and unity.

That way we might figure out for ourselves what an 'Agile Company' really means.

Value 1: Adaptability

How quickly can your company respond to a compelling product from a competitor?

How quickly can you evaluate and implement change requests from your customers?

How quickly can you implement new (government) regulations?

How quickly can you and your customers adapt new proven technologies? Or get rid of deprecated ones?

How easy is it to change the planning for your future product portfolio? And for your current work?

Value 2: Transparency

Do you know how your company is doing financially? What makes most money? What the cost structure is?

Do you know the prospects your company approaches? And what you can do to help in that process?

Do you know the return on investment for your products? What products are doing great? And which aren't?

Do you know what the other teams in your company are working on? And how they are doing?

How open are you in your communication with your customers?

Value 3: Simplicity

How easy is it to jump start new competent people in your teams?

How easy is it to visualize your products architecture? Visualize integrations with other products?

How easy is it to explain in 2 minutes what you do for a living? What your company does?

How much training do your end-users need to work with your products seamlessly?

How easy is it to deploy new versions of your products?

Value 4: Unity

Do you feel all the teams in your company are working to the same overall goals and vision?

How high is the level of colleague finger pointing when something bad happens? Or do they jump in to solve the issue?

Are team, management and stakeholder goals aligned?

Are you helping your customers to achieve their goals?

How high is the general one-for-all / all-for-one feeling?

With these kind of questions you should be inspired to help your company becoming a more agile one.

If you have great questions that should be in this list, please contribute.