Monday, November 23, 2009

continuous integration

Add to Delicious Digg this links to this post -

Countinuous integration is the last buzz word... keep reading it everywehre.

What is continuous integration
Continuous integration is a software development process, which ensures that bugs which have been detected earlier are not coming back into the code un-noticed.

It relies on a few principles:
  • use of a version control: each time someone carries out a commit, a new build a done automatically in the background
  • automatic build: as seen above, a build can be automatically triggered.
  • automatic testing: the bug raised and fixed previously must have a matching unit test which will automatically test whether it is still fixed or not.
Continuous integration and PHP
A few tools can be useful to get started with "continuous integration".

Test Driven Development (TDD)
The idea behind TDD is to write the test before starting coding. The objective of the code should be to get the test passing.

This can be nicely applied to continuous integration: whenever a bug is raised:
1) Write the unit test for it, which currently fails
2) Write the fix.

The idea is that the tester could actually build the unit test**, so that the developer can still focus on development.

Note **:It is worth considering integration testing also, using selenium RC for instance.

Labels: , ,

Monday, August 17, 2009

Buy to standardise, build to compete

Add to Delicious Digg this links to this post -

There is an interesting article about the choice between building an IT application or buying one.

This can apply to websites, which are online IT applications. And I often comes across clients or prospects who ponder whether it is worth developing a website from ground up, or use existing software available on the market.

Here is a first pointer given by the article:

Everybody knows that the more standardised you are and the more you buy off-the-shelf, the more cost effective it will be for both implementation and ongoing maintenance
This is true, especially for trivial activities such as the ability to update your website. Updating a website should be as easy as giving a phone call. And it doesn't really make sense nowadays to build a content management system from ground up. The objective is to find the right product for your business.

And an other pointer:

On the other hand, executives such as Bob Laird, IT chief architect at MCI (now part of Verizon Business), sing the familiar refrain of in-house development: “Where we tend to invest is where we can get incremental revenue … or competitive advantage,” he says.
Well I tend to agree as well. It makes sense to choose a Content Management System already available in order to give the marketing team the ability to update the site without depending on the IT team (internal or external), at lowest cost possible. However it is also important to consider developing some features from ground up, specially the ones which can give you a competitive advantage.

We recently released a stock photos website. The website is a combination of:

1) open source content management system: allows administrators to update the actual content of the page (about page, disclaimers, etc...)

2) open source frameworks (Zend, Doctrine): allows programmers to use a familiar environment, and speed up the development process. It makes also any custom development more robust and reliable.

3) custom programming: makes the website unique, with features matching exactely the business model. As business model evolves to meet new challenges, the website can also evolve rapidly to meet new requirements.

In my view, custom development is only justified when the website is intended to provide a competitive edge to a business (especially for an online business for instance). In case a website act only as a support for an exisiting communication strategy, it is preferable to select existing products.

I believe this view is in line with the conclusion of the article:
When evaluating whether to buy or build, it’s critical to thoroughly understand total costs during the software lifecycle -- typically seven or eight years. This step is important, Lutchen says, because 70 percent of software costs occur after implementation. A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers often tips the balance in favor of buying.
Bearing in mind that it can become very costly (if not sometimes impossible) to customise a commercial (or open source) software to match new business requirements in case these requirements are unique, and not covered by "common features".

Labels: , ,