How we manage software updates

0 | published by Aleksey Bobkov on Monday, September 27, 2010

All LemonStand users know how smooth software updates are. You just click a button, and LemonStand does everything. No manual file downloading and uploading to the server, no file permission issues, no compatibility problems - the store simply continues working like before the update.

This simple process is possible because of a number of techniques we use during development and testing. All updates pass through a number of steps, and on each step we carefully test the updated/added feature.

Step 1. Local development

The process starts on our development workstations. After adding a feature, or modifying an existing feature, we run a number of tests on different server environments - on Windows (WampServer) and Mac (built-in development tools, MAMP and XAMPP). When we are ready to publish the update, we commit changes to the SVN repository, and update the QA (quality assurance) website.

Step 2. Quality Assurance

The QA website is a separate LemonStand copy which is updated directly from SVN. After updating the QA website, we continue testing added features. Sometimes we find minor bugs in this step. Then we return to our local workstations, fix the code and update the SVN repository and QA website again. This process continues until all issues are fixed. When we are ready, we update the LemonStand internal repository.

Step 3. Compiling updates

LemonStand has two separate repositories which contain the most recent LemonStand code - the internal repository and the public repository. These repositories are not Subversion repositories. They are just directories on the server, which contain compiled (ZIPped) LemonStand modules. For managing the repositories, we developed a special module for LemonStand. With this module we can compile updated modules and save the compiled modules to the internal repository.

Step 4. Testing the update

On this step the feature itself has already been tested in the QA environment, but we need to make sure that customers won't have any issues updating their copies. For this reason we have another LemonStand environment, which is updated from the internal repository. The update process works in the same way as in a real LemonStand copy, so if something is wrong with the update, we'll detect it. If we don't find any issues with the update, we consider the update as ready to be published.

If we find any issues with updated code, at this point we still can revert updates, fix them on the development workstations, and repeat the process again. But in practice we do it very rarely.

Step 5. Publishing the update

Now the compiled updated modules are saved in the internal repository. So we just need to copy the updated modules from the internal repository to public. Of course, we do not copy files manually. We have a button for this. We love buttons! Once updates are published, customers' LemonStand copies can discover them and notify administrators.

Although the process looks long and complicated, we can publish a minor fix in 15 minutes after receiving a bug report. We try to make our internal business processes as efficient as possible, so we automate everything we can. The result of this is easily demonstrated by our fast, safe and easy to use update system built into LemonStand.

Share this blog post! →