Company & Culture

How We Build AppDirect

By Andy Sen / November 6, 2011

There is no magic bullet in software development. Every team and product has unique characteristics and the journey to find the perfect process is a continuous - and often painful - journey. However, there is no shame in 'standing on the shoulder of giants.' At AppDirect, we have taken some of the best practices in the software industry and modified them to fit our mission of creating the greatest app stores for business software.

What We Want to Do

1. Produce Zero-Defect software. We hate those damn insects! More importantly, our customers rely on us to find and use the applications that are critical for their businesses. We can't let them down.
2. Release Improvements Quickly. We want to make our software better for you and we want you to see it and give feedback as fast as possible.
3. Be Responsive. We want to respond as fast as possible to any kind of feedback that we get. Any plans we make must change wih circumstances.

How We Do It

At AppDirect, we use a version of Agile to prioritize requirements, and a 'Train model' using Gits great branching abilities to determine how we release the features we build.

Train leaving

In our 'train model' we release a new version of our entire code base once every week. We create a release branch from our master code base a week before the release and regression test every aspect of it. Our software integrate with dozens of other applications and supports mulitple marketplaces in several different languages. The combinations multiply quickly. Selenium covers a lot of it, but when there are some things, usually around CSS support for older browsers that still needs a human eye.

all about branches

The other cycle we have is around validating what goes into our master code base. Every feature that we do is written on a new feature branch that is based of the current master line. We use Git and GitHub to enable multiple developers to collaborate on these indivudal feature branches. Before a branch is merged back into our master branch it is validated in three different ways:

• Product management looks at the feature and makes sure that this is what our customers will find the most useful. Having the feature on a seperate branch gives us the opportunity to ensure that every aspect is well thought-out and avoids the risk of releasing an incomplete concept. Sometimes we have decided to hold off at this point and come back to the feature later.
• Our QA team tests the feature to make sure it works as expected across all our combination of marketplaces, languages and browsers. The only acceptable number of bugs in the new feature is zero.
• The code is peer reviewed by means of a 'Pull Request' on Github. It is merged into master only when the reviewer is satisfied that all necessary changes have been made.

To ensure stability, a feature branch is always merged into our master code base and never into a release branch. If a train has left the station, the feature has to wait for the next one.

Why it Works for Us

We came to our current formula after trying several variants over the last two years at AppDirect. Our processes have grown with the complexity of our solution and the number of marketplaces we support. Some things we found are:

• We need the one-week cycle to be responsive enough in our business.
• We use Jenkins for development, but Continuous Deployment to our production environement would not work for us. I would love to hear examples of multi-lingual, multi-tenanted web applications that have made it work for them.
• Lastly, but most importantly, the effectiveness of steps like peer review are magnified by the awesome, close-knit team here at AppDirect. Everyone here is familiar with large sections of the code-base and the feedback during code review as well as informal design sessions really increase the quality and maintainability of the code we deploy. No process is a substitute for a truly great team.