Releasing Software is not just packing latest version to tarball and send to SFTP server. It requires preparation and some planning to be done properly. I'll describe release procedure I applied on one of my latest projects. Supporting version control system is GIT.
The aims for releasing procedure designed:
- allow for testing window before release date
- have the possibility for examine released version to test for reported bugs
- possibility to manage existing releases (hot-fixing critical bugs)
Let's say you tracked someone broke HEAD of trunk and you want to reverse that single commit from main branch. Subversion makes very handy syntax for reverse merges:
svn merge -c -19203 https://REPO_URL
In example above you do reverse merge of 19203 revision (note "-" sign before revision number). After that merge:
- Inspect if workspace compiles without errors
- If it's OK: commit local changeset
- Notify 19203 committer about the change
In order to fix broken commit original author should do the opposite:
svn merge -c 19203 https://REPO_URL
(note there's no "-" before revision number). Then:
- Correct changeset and test if workspace is not broken
- If it's OK: commit local changeset (it will be nice to show original revision number in a comment)
You probably already know that Subversion stores some kind of metadata for all files added to repository. It's called "properties" in Subversion vocabulary. This key-value map is responsible for registering ingored files masks, file attributes, internal file content type etc.
The property I'm going to present today is "mime-type". It describes file content in similar way to HTTP header "Content-type" telling svn client how to handle the file. Typical values are: "text/plain", "application/octet-stream". Especially first part of mime-type is important:
- text/*: line-by-line merges are used, diffs are generated
- any other prefix: no text merges prepared
If you do not set this properly right you may end up with messed binary file (end-of-line conversions) or non-mergable changes in text file (that is marked as binary by mistake).
Of course during adding a file to workspace one can forget to set those properties correctly. Here auto-props comes with help. Auto-props are applied when "svn add" command (from command line or from GUI) is issued. Configuration is placed inside "~/.subversion/config" file. Here's my config fragment from one of projects.
*.csv = svn:mime-type=text/plain
*.java = svn:mime-type=text/plain
*.sql = svn:mime-type=text/plain
*.sql = svn:keywords=Author Date Id Revision URL
*.jar = svn:mime-type=application/octet-stream
Besides mime-type svn:keywords is being set in the example. It controls which keywords are expanded in source files.
What's the purpose of internal project documentation? To help people do their jobs. Developers need the knowledge to be distributed across the team, testers need definition of proper system behaviour, marketing needs information on product features to sell it.
Important knowledge that may be required by developers doing updates may be summarized in few sentences:
- Who changed recently that line of code?
- When this method have been changed?
- Why algorithm works that way?
There's simple method of automatically saving and retrieving this kind of information: Subversion (or any other version control system). How?
Aplikacja.info believes in continuous integration and frequent reases, so uses so-called stable trunk policy. That means: at any time any developer can make installation from trunk to production systems. How stable trunk can be achieved?
- any commit done to trunk is protected by set of automated tests that should run 100% clean (more critical project will use framework for a continuous build process like Cruise Control or PQM).
- "risky" tasks are done using peer code review process based on version control software
What to review?
We believe the most efficient method of reviewing code is to look at changesets (unified diffs). Then reviewer can see exact changes done by another developer to meet task criteria and codebase to review is minimized to really important parts of code (changes with some lines of context). That's why we believe forming proper changesets is very important requirement.
There are mainly three methods of inserting new commits into trunk (specified in our implementation by special "target" field in bug tracker):