Challenges of Releasing New Features

Releasing new features in today’s web-based application environment is a challenging proposition. LifeShare is comprised of a variety of web, mobile, and set-top box applications supporting thousands of users with the expectation that those users have access to those applications anywhere and anytime. This expectation translates to short downtime windows and low tolerance for buggy software applications. Our particular environment has code that resides on multiple platforms; hosted servers, set-top boxes, and mobile devices, so updating all these components adds a level of complexity. So how does LifeShare go about this tricky business?

Release Often

First and foremost, our release philosophy is based on getting features and fixes into our users’ hands as soon as they are ready. That strategy means frequent releases, even if there are just a few items that are ready for Production. Frequent releases depend on a solid source code management toolset to manage the various code branches and code merges. We use Github to manage 4 different software stacks. If a feature is not fully ready for deployment but there are other items that are ready, the release train leaves the station with what is ready. We either disable or remove the immature feature and deploy the fully-baked features and fixes.

Risk Management

We execute a careful risk management process to assure that new features roll out smoothly. The cornerstone of this strategy is that we have a hosted server Test environment provisioned that mirrors our Production environment. We restore recent Production database backups to our Test environment so that we are testing with data that will put the software through its paces as it will happen in Production. We then devote focused testing to those areas of the application that we are changing.

When we can, we use a “Phased Implementation” strategy. This means that we try to break a feature release up into a number of smaller releases in order to ensure the feature release is smooth and that there are no surprises with code changes adversely affecting the existing functionality. If there are infrastructure changes to how we store data, new API endpoints or changes to existing API endpoints, we release those changes independent of the user-facing application interface change. Once we are sure that the plumbing is working, we light up new features in the UI and begin a slow rollout of the new feature to a subset of our customer base.

For the TLDR Folks
    • So, to summarize, frequent, smaller releases allow for responsiveness to customer needs while minimizing risk.
    • Get software changes into Production, even small ones. Being responsive to customer issues is paramount to providing excellent customer service. Your release mechanism and source code tools should not influence your decision on how frequently to release.
    • Minimize risk by phased implementation to ensure that the code on the various stacks is playing nicely before the new feature is actually available via the user interface.
    • Build the ability to roll out a feature to a subset of your customers so that you are not cutting everyone over at once to the new feature. You can release that new feature to “early adopters” or a hand-picked focus group to gain valuable feedback and shake out any bugs prior to release to the mainstream user community.