[Newsletter] Create_release Script

[Paul Suh]

Folks,

Just one big thing this time around.

Creat_release Script
-------------------------------------

Part of the software release process is creating the final .dmg file  
containing everything -- the application or installer package(s),  
documentation, the source code (if the app is open source), etc. Part  
of a rigorous software testing process is to install the package on a  
testbed machine from the shipping configuration -- i.e., off of the  
disk image. As a result, when I develop software I need to constantly  
create release-ready .dmg files with everything ready to go.

This becomes even more important for larger software development  
teams. In many cases they will have separate Quality Assurance  
engineers whose job it is not to write code but to look for problems.  
In a really large software development organization, there are  
separate coding, build, and QA sections. The coders will write stuff  
and check it in to the repository. At regular intervals, the build  
team will check out a fresh copy of the full source from the  
repository and try to build it. Sometimes it will fail as one  
programmer made a mistake, or perhaps two programmers made  
conflicting changes. If the project builds, then the QA people go to  
work and see if it passes their tests. In this situation, it's  
absolutely essential that the build process be fully automated all  
the way to the end, since the build team may have no idea what the  
different pieces are and where they should go.

While the set of tasks is not complex, it is long and tedious. Let's  
look at what needs to happen:

1) Create a properly named scratch directory.
2) If shipping an installer package, build the package using either  
Package Maker or Iceberg.
3) Copy the .pkg or the application into the scratch directory.
4) Copy any associated documentation files (ReadMe, License, etc.)  
into the scratch directory.
5) If I'm releasing the application open source, create a source code  
scratch directory. Otherwise, skip to step
6) Copy the whole project directory to the source code scratch  
directory.
7) Strip out any build subdirectories from the source code scratch  
directory.
8) Package up the source code using gnutar.
9) Copy the source code package into the .dmg scratch directory.
10) Build the .dmg file from the scratch directory.
11) Delete the scratch directory, since we need to start fresh the  
next time.

That's a lot of fairly finicky work to do manually. Far better to  
automate this -- and XCode makes it easy with Target dependencies and  
shell script steps.

What is a target? To quote from the XCode documentation:

> The organizing principle of the Xcode build system is the target. A  
> target contains the instructions for building a finished product  
> from a set of files in your project—for example, a framework,  
> library, application, or command-line tool. Each target builds a  
> single product. A simple Xcode project has just one target, which  
> produces one product from the project’s files. A larger development  
> effort with multiple products may require a more complex project  
> containing several related targets. For example, a project for a  
> client-server software package may contain targets that create a  
> client application, a server application, command-line tool  
> versions of the client and server functionality, and a private  
> framework that all the other targets use.

In my projects I define a Create_release target. Since a target can  
depend on a target, I make the Create_release target depend on the  
primary target for the project. Thus, XCode will make sure that the  
primary target for the application will be built before it tries to  
run this target. The rest of the target contains a Shell Script step.  
This runs a script that does all of the above steps. I've refined the  
script step over the years. At first, almost everything was hard- 
coded. As I took the script and re-used it in more projects, I took  
advantage of XCode's ability to pass in information about the project  
in environment variables. After reading a neat posting by James  
Duncan Davidson, I incorporated some additional ideas about setting  
the human-readable version, testing for the build variant (must be  
"release", not something else), and automatically uploading the build  
to a server. He also has some really clever ideas on how to modify  
any associated appcast XML to notify users that a an updated version  
of the app is available.

James's blog posting is at: <http://duncandavidson.com/archives/664>.  
My script is at: <http://ps-enable.com/software/Create_release.sh/ 
view>. This version is intended for Leopard -- but I am actively  
working to roll support to Tiger into it as well. The problem is that  
XCode 2.4 (I haven't tried it on 2.5) does not pull in .xcconfig file  
settings into Shell Script targets.


--Paul


Paul Suh                                                          
http://www.ps-enable.com/
paul.suh at ps-enable.com                           (240) 672-4212



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2615 bytes
Desc: not available
Url : http://lists.ps-enable.com/pipermail/newsletter/attachments/20071114/072f5010/smime.bin