- In 2018 MorphAn will undergo a series of sprints in order to bring a more stable and refined product for the end user. Additionally new techniques will be applied such as moving old graphical features to WPF to reduce code duplicity.
- In 2019 MorphAn will try to fix the existent bugs of the tool, migrate to WPF and study the possibility of a different DataBase system for an improved performance.
Morhpan shared space can be found in P:\morphan
Current team composition
- Marien Boers (Product Owner)
- Menno de Ridder (Product Owner)
- Dennis Tang (Scrum Master / Developer)
- Carles Soriano Perez (Developer)
- Tim van den Aardweg (Developer)
- Gabriele Tiotto (Scrum Master / Developer)
- Ali Hadi (Functional Tester)
Focus:
Deliver a fluent stable tool that can be used by different clients and based on different models (Netherlands, Belgium, France..).
Intended program:
- Maintenance and improvement of current versions.
- Redesign of old functionalities.
Deliverables:
- MorphAn Plugin Release 1.6.1
- MorphAn Plugin Release 1.7
- MorphAn Plugin Release 1.8.3
JIRA board
In order to keep track of all issues and new features for MorphAn, we use this backlog. Which is linked with the MorphAn Delta Shell Plugin issue board (used during SCRUM / Kanban sprints).
Release Manual
When a release date is approaching a release branch has to be created.
Code freeze day: from now on the code cannot be committed in the release branch.
In this way the release code (which is supposed to be tested and working) is isolated.
The developers can still do commits on the trunk and go on with code that will be included in next releases.
IF a late minute bug is found by testers, this bug is fixed in the release branch.
When the release is ready, a signed build is generated for final acceptance testing.
To generate a signed build: The assigned developer tags the release according to procedure (check on team city)
If a critical bug is found during acceptance test and the release is not approved the bug is fixed in the release branch and a new signed build is produced.
This goes on until the release is approved.
The release is shipped.
The release branch is merged back to the trunk
NOTES: the assemblies version number have to be updated at every sprint.
The manual will be added to the build in a specific folder
After the manual needs to be committed before the build is produced and is signed.
The following lines have to be updated also in the MorphAn.wixproj
<Content Include="Manuals\MorphAn Gebruikershandleiding 1.7.pdf" />
<Content Include="Manuals\MorphAn User Manual 1.5.pdf" />
first line = Dutch version
second line = English version
Team city configuration
MorphAn currently has one Team City configuration for each of the versions released. Since the release of 1.6.1. we try to keep, as a general base, the following configurations:
- MSI Installers - Build that generates the artifcats to distribute among clients (pinned as versions)
- ZIP - Build that generates a zip release version of the software to distribute among internal users for direct testing.
- The following test categories:
- Unit tests
- Unit tests (slow)
- Data Access
- Integration
- Performance
- Windows Forms
- Acceptance
- Work In Progress
- And the following code coverages:
- Unit test
- Exteded (includes integration, data access and whichever is needed).
IMPORTANT:
The branches should receive the Trunk updates at least once per week (during development of said branches) in order to achieve a neat merge to the Trunk.
We currently have some issues if trying to merge the entire branch 1.6.1. with the trunk (1.7). Although the team city build status of the trunk (revision #39894) has the same results as the branch 1.6.X (Release 1.6.1., revision 39872), please keep in mind there might be some conflicts if trying to merge again from 1.6 to 1.7 directly.