Automating the Creation of Traceable and Reproducible Releases

As I previously mentioned, I hope to give something back to the Mac development community that is so supportive. In that spirit, I’m releasing the Perl script, under the MIT license, that I use export NewsHawker. I have learned, at times the hard way, that every build that you give to others must be traceable and reproducible. That is, you must be able to determine easily exactly which software someone has on their computer and you must be able to recreate that exact software. This is critical when supporting customers or debugging issues.

This script ensures that no files are open for edit before building the export. This is important since, if any were, the export would not be reproducible. If a pre-release version is being exported, the script updates the beta expiration date reported in the credits file, which is displayed in the about box, and in the source file that enforces the expiration. I try to automate steps that are tedious and easily forgotten. The script then builds the target based on the Release and Debug build configurations. Release notes are generated based on the tagged change descriptions submitted to Perforce. The script then creates a DMG for the Release and Debug builds based on the specified template DMG. The AppCast XML is then updated to reflect the new export. Finally, the version number in the project is incremented. This last step is critical in that it ensures that any future builds will have a different version number than the one just exported. After I verify the export, I manually submit the files that have been changed to complete the export process.

This script makes a number of assumptions specific to my development process which you may want to change. The script integrates with the Perforce SCM. If you are using another SCM, you will need to modify this script. This script assumes that Perforce change descriptions use the following tags:

  • <feature> - A new feature that was added as part of this submission.
  • <change> - A behavior change that was made as part of this submission.
  • <fix> - A bug that was fixed as part of this submission.

The text after these tags until the next newline will be included in the release notes. All other text in the change description is ignored. This script assumes that at least a shell of a release notes HTML file has already been created. This script assumes that at least a shell of an AppCast XML file has already been created and contains the “<!– insert items here –>” comment to specify where additional releases should be inserted. This script assumes the following export directory structure:

  • export

    • <major version>.<minor version> (1.0)

      • <version> (1.0.0b1)

        • notes.html
        • Release

          • <product>.dmg
        • Debug

          • <product>.dmg

I hope that the script is fairly readable. If you have any questions, please feel free to post them below in the comments.

2 Responses to “Automating the Creation of Traceable and Reproducible Releases”

  1. Scott Stevenson Says:

    This is a really interesting. May I humbly suggest choosing a more descriptive name than “Export Script?” :)

  2. geoff Says:

    Good suggestion. I forget at times that certain terminology is specific to my previous place of employment (where “export” has a very specific meaning associated with it). How about “Automating the Creation of Traceable and Reproducible Releases?”

Leave a Reply

thoughts yet to be boiled down to their essence