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!"
The principles of building software remain the same. We need builds that are:
- 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
- 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.