the process of developing, testing and shipping software
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.

Software process framework, v0.1

The document describes the process of developing, testing and shipping software.

It aims to achieve the goal of an efficiency of communication and collaboration between team members.

Related tools

  • srelease — bash script created to automate release management process


  1. git-flow
  2. release history
  3. commit format
  4. task management
  5. how to ship code to QA team
  6. automated deployment


Gitflow is a tool to decrease entropy into your repository. It contains information how to work with branches (develop, release, master), how to ship features, how to implement hot fixes.

Useful links:

Each branch should have a format that follows the naming rule:
<task number>-task_description_with_underline

Feature and Hotfix branches should:

  • start with <task number>
  • end with -task_desctiption

It's possible to use a date instead of <task number>.



Release history

To track our process of development, keep what we do and what we did,
we need to create releases/ directory.

Here is the structure of releases/ catalog:

└── releases/
    ├── current/
    │   ├── .keep
    │   ├── task-11
    │   ├── task-13
    │   └── task-15
    └── history/
        ├── .keep
        └── 2017-02-02

.keep need to keep an empty folder at the git repository

task-11, task-13, task-15 is the identifications of a task at your task management system.

The content of the task file should describe additional actions needed to be done after deployment, such as:

  • notify someone
  • run some custom command on the server

Here is an example of task file:


# updates product rating by new formula
rake features:task_11

After, we can automatically concatenate all task files into the release file


    # updates product rating by new formula
    rake features:task_11

2017-02-02 in releases/history/2017-02-02 is a date of release branch creation.

You can also additionally specify the release pourpose by adding a postfix: 2017-02-02-backend_team.

Here is a tool to automate work with releases/ directory

Commit format

Each commit should refers to task into your tast management software.

Here is an example:

[refs #task-13] commit message — if your want refer to one
[refs #task-11, #task-15] commit message — if your want refer to more

Task management

Task management is really on your own.

One thing that required is
each task should contain a link to the PR (pull request).

How to ship code to QA team

Here is the most interesting part.

When your team develops, you have many pull requests to develop branch.
Also, your QA needs to test each task.

In usual — you have a testing branch and all your team
merging their feature branches to testing then deploy.

That approach has several disadvantages:

  • you can't simply "undeploy" branch from testing
  • you need to manually merge each time
  • you need to manually deploy each time
  • you need to wait until deploy have been finished, run tasks if needed then notify QA

You need a tool to automate process of creating testing branches
from labeled PRs.

Automated deployment

When testing branch builds you need to deploy.
This process should be automated too.

The clue is that you can go even further and
automate running tasks from releases/current/*.