Bysoft China's Blog > Your e-commerce partner

Automated deployment has an important effect on your code: it leads to making your code ready to deploy. At any moment of your dev cycle, the deployment script may be called to send it to production or release: in simple terms, to be released.

Release early, release often

This is akin to ‘release early, release often’ strategy: deploying often shows that the project is making progress. Such progress is not always in the right direction: sometimes, we publish bugs. But during development time, this is normal situation, and soon, a new release will fix this. And since the bug was caught early in the process, then it will be easier to fix, and, more important, easier to forgive.

Not always finished

How can one provide code that can be always releasable? Well, first of all, between version and our current code, there is a nice piece of engineering that is called SCM : Git, svn, mercurial, fossil, CVS… call it the way you want, but this is will be the main source for the version. As long as you’re not committing to SCM, your code may not be releasable: it may not compile, be ugly, or not functional. As long as it is not committed, code doesn’t exist.

Once it is committed, it must now be part of the application. And to be releasable, it has no to break the application. First check will be compilation: if code doesn’t compile, then, it will not be releasable.

Champagne development

Coding all until it works is also called champagne development: you don’t know how sound it will pop until you actually open the bottle of champagne. At that point, you will need all your friends around, because if it pops, then you plan to fill a couple of glasses and cheers. On the other hand, if it fails, all your friends will be here to cheer you up anyway or make fun of you (yes, friends also do this).

This allegory may be applied to development: when code is awaited for too long, expectations builds up, and start going wild. As you concentrate on code, and leave your users in the dark, they will find their information with their only available tool: imagination. That’s how you end up with a nice project, well below expectation.

Breadth first

The other approach is to make the code ready as soon as possible, even if it doesn’t do much. Compile is the first level of releasable. Fully working is only the third level. In between, you have the ‘incomplete’ level : it only works. Just not fully.

Let’s take an example: how to work on a Drupal adressbook module and still have this functional during the whole process? If such a module is several days of work, then it will probably not fully work in the initial days. At this point, it is not important to have it fully working : we just need it working.

Imagine the early stage of such drupal module : the module itself is created, based on its name, with a lot of empty hooks. This will compile but do nothing. However, this is releasable: it can be sent on a new version and it will only add… nothing to the final app.

Then, from this base, you can start adding new parts. Imagine you are working on the eternal addressbook. You have then different avenues to start working: you may start from the database structure and update the hook_install; then add a few values in the database, and work in the hook_view, so that you can provide a view on existing data; then the same hook_view for a data requesting form;
You may also start from hook_menu to display the menu and an access to your new module; then the hook_view to display it. And hook_install to add a new CSS to the templating system. You may also start by the admin panel, the templates, etc.

Each of those approaches will provide you with something functional: yourself, and your user, will be able to run this application, and see a part of the job done. Not all of it, of course: development is not yet done. But part of it. Anytime.

This is the main difference with depth first. Depth first will solve all the problems as it identify them : drupal hooks, database structure, template, tests, deployment. At any point, this is development work, and nothing is releasable.

In the end there are two different approaches for always releasable.

l  Growing code organically: start by laying around all needed code to make it run. Then, add new feature on top of such code. I also call this ‘adding meat around the bone’, based on the skeleton cliché. You will probably end up with a lot of empty or constant functions, which will be placeholder for more complex and future code. Counting such placeholders is a good indicator for your progress.

l  Keep it visible: this approach is more user centric (customer, if you prefer). Only work on something that is visible. This 120 fields form will start with only 2 forms. Then, it will show 3, then 4, then 12, then 30, etc. Each time, it will add some new functionality. And if this is a 12 step payment tunnel, then it should start with a 1 step payment, then 2, then…. Keep in mind that your user will track your progress on what they see (aka template), not on the amount of work or code you provide.

If you plan to keep your code releasable, you’ll have to be able to answer this simple question: can I simply deploy my code now? This will make you ready for any situation when any even happens, out of the planning: security issue, rush publication for show off, sudden change in the customer planning, or even, a change in developer. The next guy will always benefit from starting with a working code, albeit wholly, rather that untangle a web of partially done tasks.

Damien Seguy