For deployment, 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
We were satisfying these principles using Make 30 years ago - 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 (with our tongue-in-our-cheek) the importance of the build engineer. A key point is that companies should not be looking to put an inexperienced engineer on the job and expect to get good results, and 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 effect 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 - 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 - which means get it into the hands of your customers and end users.
Back in the age of the shrink wrapped application, deployment became increasingly difficult and a real drain on resources and a restriction on growing businesses. Even with internet distributed applications, you were usually asking your users to download and run installers on their desktops. For Windows applications that means the complexity of registry updates, component registrations, DLL Hell and other similar problems. For large corporations with locked down desktops, rolling out a new application, or an 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 (or servers) which is (or are) centrally controlled. Deployment of upgrades is to 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 been a way of getting much richer applications into the browser. This gives a user experience much closer to fat client applications, and yet 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!








