Workflow - Take434/Appollon GitHub Wiki

While developing any software, a good workflow is very important to keep track of the bigger picture and get the work done effectively [1][2]. It helps to stay organized and keeps developers motivated because their work is quickly being used[1], this cuts development time and improves performance [2].
While the actual steps in a software development workflow vary from article to article [1][2][3], these general stages are similar and can be summarized as follows:

Planning / Requirement Analysis [2][3]
Product Design [2][3]
Development [1][2][3]
Testing [2][3]
Deployment [1][2][3]
Maintenance [1][2][3]

In the case of Appollon the first two stages, Planning and Product Design, are already covered in the Prototyping part of this wiki and will not be explained here.

Different Approaches

There are multiple different models as described by Kendra Risener in his study [4].
It is outside of the scope of this wiki to explain these. In the case of Appollon it seemed unnecessary to follow any principles strictly, since there are only two developers involved.

Workflow in Appollon

Instead it was decided to follow an approach loosely inspired by SCRUM:

As the first step it was necessary to define features wanted in the application to read more about this, refer to this wiki page.

After that a prototype of the site had to be developed, this process is described in the Prototyping-Section of the wiki.

The Development step was achieved by defining features that should be implemented in this GitHub using Issues. This is comparable to stories in SCRUM [5]. These features were then realized in a branch other than the default, which was main. In the case of Appollon both developers, Tim and Jonas, had one branch, in which they implemented the feature they were working on. This is not the way things are done in SCRUM, here each feature would be in its own separate branch [6]. It was chosen not to follow this pattern, because each developer would always focus on one feature, complete it, merge into main and then use their personal branch for the next feature, thus achieving the same result.

Testing did not take place as a separate stage, features were tested by both developers after implementation.

The Deployment stage has its own wiki page discussing the strategies and problems involved.

Since the site is not yet finished the maintenance step has not been reached.

Quality Control in Appollon

To avoid bugs and improve code quality in Appollon there are a few quality control measures in place. Quality Control is, in comparison to Quality Assurance, describes more basic testing to keep code quality higher [7]. This can be done automatically by using a code linter together with a GitHub action.

Code Linters

A code linter is a dedicated program that detects errors in code [7] and points these out. Linters are language specific, as they define rules, that are only applicable to the programming language the linter was written for [7].

GitHub Actions

GitHub describes GitHub Actions as a "continuous integration and continuous delivery platform"[8]. It allows for the creation of pipelines, that are run by GitHub Runners, dedicated virtual machines, and can be triggered on a number of events that might occur in the repository [8].

Automated Linting

In the case of Appollon a GitHub Action was configured to run every time something is pushed on any branch. This action then runs a code linter to check for any formal / syntactical errors in the code that was just pushed.

Branch protection rules

Furthermore there are branch protection rules in place to make sure nothing can be pushed on the main branch directly. This means, that any changes have to be approved through a pull request before being merged into the main branch.
A pull request is a way to "tell others about changes you've pushed to a branch" [9]. These changes are requested to be merged into another branch after review from another collaborator. It is also possible to add more requirements that have to be met before a pull request can be accepted [10].

In Appollon the code linter is run when a pull request is created and it has to succeed without any errors before the request can be approved and merged. This ensures, that the code on the main branch is always up to the standards set in the linter, thus creating a higher code quality.

References