wiki:ReleaseAutomation

Version 2 (modified by radix, 7 years ago) (diff)

add links to tickets

Release Automation

Tickets related to this spec:

  • #2350 - release process should use one branch for all projects
  • #2353 - use a time-based version number
  • #2308 - Test twisted's release automation

Twisted has a tradition of irregular, slow releases. In order to rectify this, we need to create a system in which we can confidently create, test, and publish Twisted releases with minimal user interaction. Only then will it be feasible to have regular, scheduled releases.

The only necessary points of human interaction while creating a published release are as follows:

  • Choosing versions (may become obsolete if we move to a date-based version number)
  • Creating the NEWS file (there is a LOT we can do to make this much easier, by parsing and massaging trunk commit messages)
  • Choosing the quote of the release (but this is so neglected that we should probably just stop)
  • Sending the email to announcement lists (but this could be automated to the point where the email is shown With a "send out? y/n" prompt.

Beyond this, everything can be automated and tested.

Given all the failures of maintenance of our previous automated release systems, release automation code must be written test-first with full test coverage. In addition, a build slave should be set up which creates a Twisted release, installs it (and the included zope interface package) into a completely clean environment, and runs the full test suite. A couple of acceptance tests like "are the packages that should be installed actually installed" could also be useful.

Our release process involves creating SVN branches. Testing of our automation in this area may be problematic. A couple of options are to use svk or bzr(-svn) branches instead of server-side SVN branches to maximize isolation for testability. We could also just run the automated tests against a local copy of the SVN repository.

Testing automation of web site publishing could also become problematic. There are a couple of options: push changes to our wiki, or add dynamic web code to our wiki to automatically display current release information based on an external source. Frankly both of these things are dreadful to test.

Publishing the static content to our web site should be fairly straightforward and easy to test, if written properly.