Disclaimer:
These pages about different languages / apis / best practices were mostly jotted down quckily and rarely corrected afterwards.
The languages / apis / best practices may have changed over time (e.g. the facebook api being a prime example), so what was documented as a good way to do something at the time might be outdated when you read it (some pages here are over 15 years old).
Just as a reminder.

Release process workflow

an example workflow how to handle release/testing of code

See also Bug processing workflow and Release/test server setup.
This process follows the feature / bug request through the different stages from idea to the release. Note that I have done some overlapping with the Bug processing workflow, just to try to be as clear as possible.
The tools used are Mantis / Git / Github, but the process is generic so could be applied to any issue tracking / version control tools.
See full description of the process below the diagram.

Release manager
merges to trunk
Release manager
- applies sql on stage server
(if possible without distrupt production)
- informs product team that code is on stage server
Developer set
- all mantis tasks to "Resolved"
- pivotal tasks to "Delivered"
Bugworkflow process
Release manager sets tag: rel_XXX
- apply sql to test db
- check out rel_XXX on test server
- inform developers that code is on test server
Check out branch and
sync to production server
Failed bugtests
that must be fixed?
Are there code in Trunk
that cannot be released?
Create new branch
rel_XXXa
based on rel_XXX
Bugworkflow process
Failed bugtests
that must be fixed?
Merge new branch
over to Trunk
Done
DEVELOPER
RELEASE MANAGER
Developer creates new
experimental branch exp_
Is it an experimental feature?
When the developer is ready
he tags the branch exp_XXX
and put it on his own dev server
Is the code ready to be released?
Developer plans to code feature/bug
Developer Commits code
in his branch
Done
Release manager check out
tag rel_XXX on stage server
Release manager check out
tag rel_XXXa on stage server
Fix code in new branch
Release manager sets tag: rel_XXXa
- apply sql to test db
- check out rel_XXXa on test server
- inform developers that code is on test server
Yes
Yes
Yes
No
Yes
No
Yes
No
No
No
Release worflow process

ROLES
  • Release manager Initially the (senior) developrs that are most familar with the code can have this role
    As well as looking at code, the reviewer need to have a grasp about possible side effects that can appear elsewhere in the code base, hence not everyone is initially a code reviewer.
    It should be some other developer then the one that coded it, i.e. if "Dilbert" wants to release code he would ask "Dogbert" or "Cathy" to review his code.
  • Tester internal people or/and external people depending on how much testing there is, and what needs to be tested. if it just some small bug fixes etc that shall be tested, it is probably quicker turnaround to do it internally
BRANCHES
Naming convention:
every developers branch is simply their name, e.g. "dilbert", "dogbert", "cathy", etc
These are the branches that are considered to contain code that should be tested and released and are regularly merged into the trunk

Branch that contains the developers "experimental" features (see further down for description) is simply the name followed by "_experimental", e.g. "dilbert_experimental"

Developer branch A
Developer branch B
Developer branch C
Developer experimental branch C_experimental
Trunk T

SERVERS
  • Stage server - works with the production database. Is used for us (design, developer, product team) internally to review code changes etc and provide feedback
  • Test server - has a separate test database.
    On the test server there exist a "main" server that is used for normal testers, but each developer also have their own port where they can put their experimental code so it is visible for designers etc.
Mantis:
  • DEVELOPER - virtual user, where all open tasks are that the developers can take on
  • TESTER - virtual user, the tasks we want the testers to test
  • FAILED - virtual user, where testers assign all bugs that failed when testing
Statuses in Mantis
  • Resolved - the bug has been fixed, but not yet verified as fixed by a tester
  • Closed - the bug has been fixed on the test server, we consider the bug is solved and now forget about it.

THE WORKFLOW

Developer commits his code to his branch A,
release manager merge stuff from A to main trunk T.
The release manager inform the developer A that the code was accepted, the developer A set all the relevant bugs to "Resolved" / the pivotal tasks are set to "Delivered"

The developer A informs the relevant parties (e.g. asking the designer to test it out) that the stuff is on the stage server. If it is just a bugfix it is enough that the developer himself verifies that it works as intended on the stage server.

When it is decided that something shall go live (i.e. designer/developer/product owner are happy), that corresponding tag is checked out on the test server TS by release manager.
Any sql changes are applied.
All bugs that are marked "Resolved" are set to solved in version=XXX where XXX is the tag that has been checked out, and assigned to TESTER

The testers are notified and test the resolved bugs, any bugs that fail are set to re-opened and assigned to "FAILED" any bugs that have been fixed are "Closed"

After testing, the release manager checks any bugs that are assigned to "FAILED", and determines if the code should be released anyway, or if any of the bugs need to be fixed first.
Bugs that is determined they do not need to be fixed first, are assigned back to "DEVELOPER" (and priority / severity might be adjusted).

If any bugs needs to be fixed, either:
a) it is determined that no critical conflicts have been checked into the trunk T, hence the developers can take care of these bugs as normal and the process starts all over (with perhaps additional code from other developers)
b) in the meantime some conflicting code changes have been merged over into the trunk T.

In case (b):
a new branch H is created based on the tag when the code was submitted to stage.
The bugfix is commited into the branch H. Any code that goes into branch H is merged over to the trunk T, afterwards the code is put on the test server and re-tested.

If no bugs need to be fixed; release manager applies any sql changes to the stage server (if possible) and put it on the stage server and informs production team for a final check of critical stuff with production data, after that it gets released.

Nothing that is not ready for release does not get commited into the developers branch.
If the developer works on a big project that they want to secure, they can create temporary branches that they commit to, and then merge over to their "real" branch.

Putting stuff on stage / production, means checking out and "compile" the code from git, (and perhaps rsync, depending on how we set it up).
The important bits is that we should have scripts for this and that the code comes straight from git.
I.e. no manual copying from our code base, to make sure that we know exactly what is live at all times.
In the scripts we can also add stuff as automatic emails, tagging etc as we wish.

EXPERIMENTAL FEATURES

For example features that the product team want to look at, but it should not go live in the near future.
  • These are checked into a different branch of the developer; _experimental
  • The developer tag the branch when he wants to put it on the developers own test server (under the developers own port), the developer then himself checks out that branch on his test server and inform the relevant people (e.g. designers).
  • When the experimental feature is considered stable, it is merged over to the developers main branch.

    EXAMPLE

    See attached diagram below:
    developer A is developing stuff, commit into her branch A.
    Release manager reviews code, merge it over to trunk.
    The code is tagged "rel_20130313" and put on the stage server. The bugs are set to "Resolved" in Mantis.

    Meanwhile, developer B has developed stuff which is ready. It is merged over to trunk T, and planned to go next on the stage server.

    However, the designer needs a text change for developer A's code.
    A hot fix branch is created from tag "rel_20130313".
    The hotfix branch is put on stage/test server, and the code from the branch is merged over to the trunk.

    A
    Trunk T
    Tag: rel_20130313
    B
    Hotfix
    Tag: rel_20130325
    At this point we realize we need
    to do a fix to rel_20130313
    so we create the hotfix branch
    bugfix
    Code tagged and put on
    test server
    Hotfix is tagged, tested
    and released
    Tag: rel_20130313a
    Code from B (and hotfix code) tagged
    and put on test server
    and the process continues as before
    C
    Tagging and putting
    experimental code
    on test server
    Tag: exp_20130315
    C_experimental
    When not experimental anymore,
    it is merged back to the developers
    normal branch

    More programming related pages

    Workflow: Release process
    Workflow: Bug tracking
    Teambox (Redbooth) - Mantis connector
    Design Patterns
    Git & Github
    		Go / Golang
    CVS
    CVS backup script
    Distribution process
    Installation script
    		Java Server Faces
    Facelets
    jibx
    jBoss
    jBpm
    		Perl tips
    Perl links
    PostgreSQL
    Python / py2app
    Shell scripts
    		Xslt
    Node.js
    Facebook / Opengraph
    PHP developer notes
    Redbooth API through php
    		Website optimization
    jqTableKit demo
    Javascript / html / css links
    		•