Participative software development in practise
By Robert Sirre • published September 14, 2020 • last updated October 24, 2024
Basically all software development is:
- Turning coffee into cool things
- Fixing broken thing (due to lack of coffee, or coffee-overdose)
Not only do we work on features and fixes on a one-by one basis; sometimes we also do the management art of juggling: work on different things within the same time period, with different stakeholders, internal (platform improvements) and external (tailoring of client wishes), with varying urgency and complexity.
The context-switching required for this is not something we strive for, but to a degree it is a fact of life. Being able to do so with ease is key: a strategy is needed.
The product of our labor is primarily source code. This product is being worked on by multiple developers in multiple teams at the same time.
When two developers can start out with the same code, work on two different features end up with two different versions of the original software. This process could be represented as a tree with multiple branches.
Using version control these branches can be merged together. In the graphs below our strategy of the process of branching and merging is explained. Each piece of work is presented by a dot, and can be deemed just ‘work’.
Gitflow and continuous development
Following a DTAP (Development, Test, Acceptance, Production) approach, most of the branches in the graph on the right have an environment reserved for them, where they can be reviewed by the stakeholders:
Our development environment shows all new finished features together, from the development branch. As this is the first time these features can be admired together, this environment is also known as the integration environment.
From our development branch we create a release from time to time, usually in a weekly cadence. This release, containing multiple features as a set, can then be tested on the test environment (usually for internal testing) and later can be approved for release on the acceptance environment (usually by clients).
Although this is very nice, these features are only visible to the stakeholders in a relatively late phase: the features have already been integrated with others when having them tested.
This results in features that need some work blocking other features from making it into production, which can be stressful and disappointing.
Software development is about shaping ideas. The initial phase of shaping these ideas works best by using fast iterations. As stated above, it’s imperative that all stakeholders are actively involved early in this process.
Like most design processes, it’s nice to have something tangible during this process.
In some industries a drawing or a scale model may suffice, in our line of work simple proof-of-concept piece of software is possibly the best way to get a concrete idea of where the idea is going.
Enter: Gitflow plus
Nothing beats an early test-drive of a feature, in order to have it individually tested, tuned and finally approved to make it into the next release.
To allow this, we have created a preview environment: a playground for early-access features. They can be tested, rejoiced or sent back to the drawing board, without blocking anything or anyone! When a developer has finished a feature, it can be merged into a temporary, never-merged branch, aptly named the preview branch.
When an individual feature is deemed good enough for the next release, it just follows regular Gitflow logic and the feature will be merged to the development (or integration) branch, making is ready for the next release.
Note: this article is simplified and does not showcase, nor does it talk about database migrations.
Read more about Gitflow at nvie.com : A successful Git branching model
