How do I go from “here’s the zip” to a good release strategy?

I can write code, resolve dependencies, and get my program to run on my computer; I have no idea where to go from here though. How do I get the software ready for distribution?

The school environment has taught me to do a few random tests by hand, make sure nothing is obviously broken, then throw all the source files into a zip and send it off. This is all that’s needed to get a good grade is most CS courses. Nobody taught me how to release to real users.

The only clues I have are a few phrases like “automated builds” and “continuous integration”, but I don’t know what these mean. How can I properly distribute my work? How can I make it easy for others? How can I move beyond “here’s the zip” releases?

In the real world you really want to come as close to just hitting a button and having everything be automated as you can. If you are installing yourself it’s worth the effort because of the time it saves and because you want to make it very hard to make a mistake with live software. If you aren’t then it’s worth the effort because in almost all cases few people will deal with a difficult installation process.

This can be quite a lot of work but it’s conceptually pretty straight forward. You have to write code that verifies that the transitive closure of all dependencies are satisfied and either fix anything missing or have a good error message. If there are installation options that you can’t know in advance you have to support setting those via a UI or script or both. You have to play nicely with whatever standard installation mechanism(s) exist in your environment.

Dependencies might not just be files, but might be things like making sure windows registry entries the program relies on are present, configuring a web server for the program, etc.

Basically you have to do programatically everything someone would do by hand, handling all the different possible scenarios.

Automated build is a pretty self explanatory term. A lot of times the build doesn’t get quite all the love it needs, and the build process is written in a document with a lot of steps. It’s generally worth the effort to have some form of configuration driving a completely automated script. That’s an automated build. Usually part of the build is running automated tests to make sure that not only does the build produce a program, but that at least the tested parts of the program actually work.

Continuous integration isn’t feasible without an automated build, which is a big reason an automated build is worth doing. It means that the build gets run automatically using some scheme (like “whenever new code has been checked in since I finished the last build I was working on”). Generally a big part of the value of this is that the build runs automated tests, so if code changes break some distant dusty corner of the program you find out automatically and fairly quickly. There may be some value in just knowing it all still compiles though.

Distributing your work and making it easy for others would involve making an installer and following whatever conventions your audience might expect, like putting in an app store, or a source code repository. There are a lot of tools in various environments that, given a name, go find code for you and install it. Your code can participate in that if you follow all the rules needed for those tools to work.

I’ve been incredibly general because the gory details vary quite a bit in different environments, so a specific answer would depend greatly on exactly what you are doing.

You should do this incrementally. The next step after giving someone a zipfile is giving them an installer that takes care of setup for them.

First, you should learn to manually build an installer. Have a look at InnoSetup, a free program for building installers. You give it a script file containing a list of the things that you want to install, (and other settings, if you need them,) and it produces a Setup.exe. Learn how to use it (or another installer-creation tool) first.

Automated builds means running the entire process, from checking out the code from source control (have you learned how to use source control yet?) to building to creating the installer to uploading it to your server, from a script. Do not try to automate anything until you first understand how to do it manually. Automating something is always harder than doing it manually. But once you understand all of the above steps, you can start to write build scripts. A typical script would look something like this (pseudocode):

SVN Checkout (project folder)
command line compiler ("project folderteststest harness.project")
if run ("project foldertestsoutputtest harness.exe") <> 0 then
  Abort ("tests failed")
command line compiler ("project folderFull Build.projectgroup")
Installer Compiler ("project folderinstallerScript.is")
FTP upload ("ftp://myServer.com/downloads", "project folderoutputsetup.exe", username, password)

This is greatly simplified, of course, but that’s an overview of the general idea.

Continuous integration takes things a step further: it puts a hook into your source control server so that it will kick off an automated build process every time anyone checks code in. This way, you get more-or-less immediate feedback if someone breaks the build. It’s not something that’s particularly useful on small-scale projects, but at a larger scope it can be helpful.

This depends on the language, frameworks, IDE, Source Control and technologies used in general. That being said you can typically create an installer package.

Filed under: softwareengineering - @ 14:06

Thẻ: automation, builds, continuous-integration, release, testing

Thiết kế website giá rẻ

Danh mục

How do I go from “here’s the zip” to a good release strategy?