To understand why the Build/Release process is what I consider the most important part of any project, I first have to define what I consider to be the parts of the Build/Release process.
Build/Release starts from when the first line of code is created and continues all the way to when a user installs and runs your application or accesses some part of your server or service. Yep, it’s inter-woven into all aspects of a project simply because if you don’t have quality steps all thru that process you end up with crap. It may be pretty shiny crap, but it’s still crap.
I find one of the better ways to visualize Build/Release is to work backwards from the customer and outline what it would take to research and solve any problem the customer is having. This often is classified by developers as bugs, but I’ve gotten more accustomed to thinking of them as Issues – because sometimes it’s not a coding defect that is causing the Issue, but rather a process or UX problem.
Your project, let’s call it twerzle has just been installed on your customer’s laptop and bang – they have a problem. What happens next depends on how prepared you were during the Release part of the Build/Release process.
- Do you have a support link or area on your project page
- Is the version number or other project identifier easily discovered or located
- Do you have a way for the user to give you the information you need without them having to be a digital forensics major?
These items will change from release to release, so you need to have outlined what steps are required to update your web site and secondary documentation – you do have a README file or CHANGES file and that information is accessible right? So our twerzle user has found your support link on the page they downloaded the app and that page also has what the latest version is so they don’t have to guess – what is next?
- Is this link a simple email box? Is someone assigned to answer the emails? Do you have an auto-responder?
- Is the link to a support forum? Has someone been tasked to monitor the forums? Is there a sticky-post showing the README contents?
- Is the link to an IRC forum – better hope you have 24hr coverage because that’s a fast way to an irked user if no one is around to answer them 24×7
So, community support methods and practices aside (that’s a whole other subject that I don’t even begin to understand fully), you now have a support request from a user and for the sake of our example, it actually contains a version number and a complete description of the problem. This is when you find out if you have a real Build/Release process.
Given the version information for the issue, can you now go back and install a clean instance of that exact version? No, I am not talking about a developer having what they think is a clean checkout of the source. I am talking about being able to retrieve the exact distribution image and then being able to install it on a computer that has NO development environment. Yep, this step is where most projects fail as they depend on developers to reproduce issues. But that works only for coding defects – not for application usage or environment issues.
That is what the crux of Build/Release is, the ability to have all of the information that goes into a project’s distribution available to back-track and solve any issue a customer may have. What goes into this nebulous hand-waving bundle depends on a lot of details, but it almost always boils down to three items:
- Reproducibility
- Documentation
- Deployment
Reproducibility means simply, do you have available all of the source code, the libraries, and the environment needed to build said source code available for each release you have made. If you do not, then you cannot truly reproduce a release and while you may be able to figure out what the problem is, you will not be able to fix it for that release. You will have to fix it in the trunk and hope that the code is the same and that the fix doesn’t break other things.
Documentation is all of the things that make up the how and why of the building and creation of a distribution. What versions of libraries are needed, what steps are to be taken, what tools and assumptions are being used and what the process is to bundle all of that into a distribution. Yes, here source code and scripts do count – as long as you include them in the distribution snapshot :)
Deployment is basically all of the above but from the point of view of non-developers. What is the process to deploy a new release for testing, how do you take the developer generated items and QA them. Once they are tested, what are the steps for deployment to the public. Do you have upgrade steps, are there extra tools and/or documentation that needs to be generated for upgrades versus new installs.
I realize I have only given a very short overview of what I consider a Build/Release process is but most of the time the above is what a lot of projects don’t do well for a lot of little reasons. I myself need to sit down and try and map out how I will communicate more details since it is so project specific.
Thanks for reading and I hope my bumbling attempt at communicating this process has come across in a useful manner.
