Build and deployment are subjects which are dear to our hearts and we have written quite a lot about them over the years. While the details may change from year to year as technology evolves, the underlying principles remain the same. Regarding building, we are going to take the opportunity to provide a guide to some of our previous articles that still hold true.

We suggest that the rise of web applications and Web 2.0 shows deployment as one of the main drivers for many aspects of application development today. Thus, our headline "Deployment is King!"

Agile Building
The principles of building software remain the same. We need builds that are:

• Reliable
• Repeatable
• Incremental when appropriate
• Fast (enough)
• Automated, not dependent on manual steps

Thirty years ago, these principles were satisfied using Make.  The challenge has been remaining true to these principles as applications have become larger and as the technological landscape has evolved.

In The Renaissance Builder we highlighted (tongue-in-our-cheek) the importance of the build engineer. A key point is that companies should not put an inexperienced engineer on the job and expect to get good results, yet we see this frequently! Make sure your build engineers are technically capable and also respected by other members of the team. This will ensure that the requirements of your build system don't become neglected.

Building for Success reviews some standard working patterns and their effects on the build. It goes on to look at what affects build velocity.  In summary: 

• Fast machines
• Shared build servers
• Incremental builds and different build tools
• IDEs
• Shared library problems 

The Importance of Software Builds: Building Earnestly addressed the costs of a manual build process and the importance of getting people started and motivated to improve their process.   

Our article “Agile Build Promotion: Navigating the "Ocean" of Promotion Notions “ covers build patterns (private system build/integration build/release build) and build promotion patterns, by promoting them into deployment.

Continuous Staging: Scaling Continuous Integration to Multiple Component Teams shows the use of a staging area as part of continuous integration, and leading to release builds.

Deployment is King! Web 2.0 and Beyond
The greatest application in the world is not much use if you can't deploy it; this means getting it into the hands of customers and end users.

Back in the age of the shrink-wrapped application, deployment became increasingly difficult, a drain on resources, and a restriction on growing businesses. Even with internet-distributed applications, users were usually asked to download and run installers on their desktops. For Windows applications, that means the complexity of registry updates, component registrations, DLL frustration and other similar problems. For large corporations with locked-down desktops, rolling out a new application or update was a major piece of work.

So, what if you can get your application into the hands of end users without them having to install extra components onto their desktops? This removes a significant hurdle to adoption and makes it much easier to expand your market.

Early web applications were based on HTML, with server side applications doing the work. This made deployment much easier, as users are accessing a server(s), which is centrally controlled. Deployment of upgrades involves a few servers rather than thousands or tens of thousands of desktops. The problem with typical web applications was that they were a very poor relation, in terms of user interface and capabilities, when compared with fat client applications.

So in response to this problem, Web 2.0 technologies such as AJAX have provided a way of getting much richer applications into the browser. This gives the user an experience much closer to fat client applications, but with the deployment advantages of a server based web application.

We contend that the deployment advantages of web applications have conquered a major portion of the application development landscape:  deployment is king!

Silverlight vs. Flash vs. Flex vs. AJAX (HTML/CSS/Javascript)
There is a battle being fought over the technologies to be used for web development.  Brad Neuberg explains in his blog post regarding the competitive forces at work between Microsoft's Silverlight, Adobe's Flash and Flex, and the existing boundaries being pushed via Javascript, CSS, AJAX, etc. 

As Brad mentions, “At this point, in April 2008, Silverlight's problem doesn't seem to be its openness. Silverlight's problem is its installed base, or lack thereof. The only statistic I was able to find was a Microsoft claim of 1.5 million downloads per day. It's hard to compare that with the study commissioned by Adobe listing Flash 9 penetration at better than 95%, but clearly the installed base Microsoft is looking for is not yet there, given that MSN Video is still Flash-based. “

In another corner (to Microsoft and Adobe), we have companies such as Appcelerator, which provides open source development environments to aid developing Rich Internet Applications (RIAs). 

AJAX Web Application Development
There are a variety of issues to consider, including the language and the framework used for your web application. Issues include:

• Productivity of development (and enhancement)
• Performance and scalability
• Ease of deployment
• Ease of finding hosting environments

Appropriate choices need to be made amongst these conflicting requirements. Languages such as Ruby and the Ruby on Rails framework have rightly become popular because of their productivity. Yet it has turned out that deploying and managing the production applications was not that easy.

There are a variety of reasons for the popularity of PHP as a web development language over Ruby or Python:  “Why is it important that PHP has a CGI like model? Mostly because it lets two groups separate their work: system administration types (including hosting companies) set up the environment, and developer types use the environment, and they don't have to interact much. The developers are empowered, and the administrators are not bothered. “

As Ian explains, PHP applications power many web applications due to the simplicity of the deployment and ongoing administration. This includes large content management systems such as Joomla, which powers CMCrossroads itself!

Happenings in the Ruby/Rails include: 

• Passenger (or mod_ruby) and Ruby Enterprise Edition:  Advantages include improved performance and reduce memory requirements
• Capistrano:  A tool to automate deployments, originally targeted at rails applications, but applicable to most applications.  From an agile point of view, this provides the "one click" deploy option.
• Hosting companies targeting Rails applications: Initially a Rails application could only be deployed if you had your own server (either directly or via an ISP). Cheaper shared hosting options just did not exist. These days, companies such as EngineYard provide inexensive shared hosting for rails applications out of the box. The fact that there is a market here is a sign of progress.

Getting SaaSy With Your Mashups

The rise of the Software as a Service (SaaS) model is based on centrally managed, easy to deploy software, with a variety of business reasons behind it.

From Wikipedia: “Software as a service (SaaS, typically pronounced 'sass') is a model of software deployment where an application is hosted as a service provided to customers across the Internet. By eliminating the need to install and run the application on the customer's own computer, SaaS alleviates the customer's burden of software maintenance, ongoing operation, and support. Conversely, customers relinquish control over software versions or changing requirements; moreover, costs to use the service become a continuous expense, rather than a single expense at time of purchase. Using SaaS also can conceivably reduce the up-front expense of software purchases, through less costly, on-demand pricing.”

Salesforce.com has its own definition of SaaS and how it is different.  Mashups are defined as: “In web development, a mashup is a web application that combines data from more than one source into a single integrated tool; an example is the use of cartographic data from Google Maps to add location information to real-estate data, thereby creating a new and distinct web service that was not originally provided by either source.”

Both SaaS and Mashup applications reduce the costs of deployment. Phil Wainwright on ZDNet writes:  “Much has been written about the promise of mashups to become serious business tools - as well as the obstacles and challenges they must overcome along the way. It's only now, more than six years since the notion of mashups first came to the forefront (they acquired the name a little later) and that SaaS vendors and integrators are beginning to realize the full potential of the mashup for enterprise applications. As this first wave of commercial enterprise mashups comes to maturity, it is making clear once and for all the mashup's seminal role as the disruptive motor at the heart of the on-demand model.“

Making Web Applications into Utilities
For other web application developers, there are a variety of challenges, including scalability and reliability of your servers.

Industry heavyweights such as Amazon with its EC2 (Electric Cloud Computing) and Google with its Google App Engine are providing services.  The basic idea is that if you conform to the particular requirements of the service, then as a startup you simply pay for what use and not a penny more. Even heavy users can make savings over having to host their own infrastructure. Deployment problem solved, but at the expense of conforming to the framework set by a chosen provider.

Browser Wars - Part Deux
As we discussed above, the rise of Web 2.0 is based on the installed base of browsers with their associated capabilities and inconsistencies as regards CSS and Javascript support. Microsoft's Internet Explorer retains the lion's share of the installed browser base but with Firefox in the ascendant, particular among those with a more technological bent and not a locked down desktop.

Into this mix, Google launched their Chrome browser. Some media hype would have reflect that this is about replacing the operating system and, as such, is an attack on Microsoft with its Windows monopoly, while others consider this a slight overstatement.  Google certainly has clout, and indeed the beta of Chrome is already good enough to influence the direction of browsers and the continuing rise of the web application using Javascript and other AJAX technologies. The jury is out.

Conclusion
Building is getting better and more agile, but you neglect it at your peril.  With the rise of Web 2.0 and its successor, we are convinced that the requirements for successful (agile) deployment are driving the choice of technologies and application development frameworks.

For those developing non-web-based applications, the underlying deployment drivers of Web 2.0 are also valid.  Do whatever you need to do to make your deployment easier and consider its requirements at the start of the lifecycle of whatever application you are building.