Development Process » History » Revision 3
Revision 2 (Hans-Martin Haase, 08/11/2015 11:54 AM) → Revision 3/7 (Hans-Martin Haase, 08/11/2015 02:44 PM)
h1. Development Process
The high level view of the development is probably best explained by the following picture which includes also the quality management and the community involving processes. It is the ISO 9000 inspired Quality Management System used in the project.
!{width: 50%;height: 50%}oec_way_final-dh.png(Open eCard development process)!
For a better understanding of this development circle it is necessary to know the roles which are setup in the process of development.
h2. h3. Roles
The project comprises the following roles:
* _User_: This person has read access to the public git repository and to the download area for release packages. He is allow to submit bug reports and improvement suggestions. This subject is settled in the user community.
* _Developer_: A person in the role of a developer is here part of the developer community. The difference to a normal user is that the developer is involved in the programming of new features or the solving of bugs. Also he is responsible for developing the components that have been assigned to him in accordance with the project guidelines (see next subsection as well as the [[code-style|code-style guidelines]]) and the overall project architecture. He must also comment and document his code properly.
* _Core Developer_: The core developer is a project member which contributes regularly and is mainly involved in the development and extension of the application core. There is no other difference to an other developer so all rules applying to an developer are also relevant for a core developer.
* _Tester_: He should review the code of a developer and is part of the decision process about which commitments are accepted for the main code base.
* _Manager_: This person is responsible for creating releases in time. He must also make sure that a pre-release version is thoroughly tested by the tester before releasing it to the public. This should guarantee that a release is widely free of errors. The manager should also distribute new releases to the users and all other roles.
* _Project Manager_: The project manager is responsible for steering the entire project, collecting new features, evaluating them and assigning respective development tasks to the developers for realizing these features.
The _Project Manger_, _Manager_, _Testers_, and _Core Developers_ form the core team which is responsible for development of application core. They may be assisted by developers from the developer community.
So now may want to know how the development process of a new release (minor or major release) is initiated and what's happening in the phases of the development. This will be the subject of the next sections.
h2. h3. Initiation Phase
On the very beginning there have to be defined what the development goals of a new release are. This includes evaluation of the feasibility of new features and the necessity to fix open bugs also the stability may be subject of decision process. In order to archive the goal definition the feature and bug trackers are considered to get an overview about what the needs of the community are to improve the acceptance and increase the spreading. Furthermore there is the core team which may have ideas they want to implement to simplify the internal structure or module communication or whatever. All the information are gathered by the _Project Manager_ and discussed with the manager. In the end the features to implement and bugs to fix are transformed into tasks which are assigned to specific developers which are than responsible for the realization. Also an release date and a feature freeze date is stated, the feature freeze is around two weeks before the release date.
h2. Implementation Phase General Quality Assurance Guidelines
In this phase the developers implement the features or solve the bugs according # *Only atomar commits* should be uploaded to their assigned tasks. Features have to be implemented until the feature freeze date else repository. Each commit should not comprises more than 150 changed lines. If more changes are necessary, the feature will upload should be rejected and separated in several commits.
bq. TW: I'm not sure if a max_line restriction is part very sensible. Especially when adding new features, a lot of boilerplate code (class structure etc.) is being added, so the next release. After the feature freeze it is just allowed to commit fixes 150 lines rule can not be applied anymore. However I agree, that this makes sense for existing code. While bugfix commits. In my opinion, the implementation the developer may commit his work to the development branch if the commit full fills the minimum quality requirements which are:
# *Only atomic commits* important points are.
1. Commits must build.
2. Commits should be uploaded to represent either a bugfix, an API change, the repository. This means the application still builds with of an API change, a cleanup/merge change, new features, the commit, the overall change integration of new features, ... The important part is, that it is explainable clear in one sentence (commit log), the commit shall log) what happend.
3. Commits should be as small as possible and it possible.
4. Commits should be reversible without breaking the software. When changing shared functionality this This is most certainly not true. true when changing shared functionality, therefore should.
Perhaps atomicity is already the correct term, but we should mention the implications explicitly.
# *Untested code must not be committed*. Each class must comprise at least a JUnit test. The new code must be in line with the current development code state and must be able to be compiled and run without errors.
# *Undocumented code must not be committed* to the repository. Each code file must include proper comments according to the project style guidelines in Javadoc format.
Next to the requirements for the commits there are also requirements regarding to the style of the code. The code styling is described in the code style guide which may be found [[code-style|here]].
A person is nominated by the project manager (usually a tester or release manager) who is responsible for supervising the commits of the developers and reject a commit if these rules are not obeyed.
As stated above h2. Test Cycle
bq. Benedikt could write how the development phase lasts until individual developer can use jenkins to observe whether the feature freeze which also code is the entry point ready for the a merge request or not.
+ Other test phase.
related stuff
h2. Test Phase Release Cycle
During # Each *release cycle* lasts 8 to 12 weeks.
# At the beginning of a release cycle, the project manager assigns the tasks which should be realized in this phase cycle to the developers. He also announces the planned release date.
# At least 2 weeks before the release date, the release manager and closes the tester test current release branch (*code freeze*). Only error corrections may now be committed to this branch. New features must be committed to the branch of the next upcoming release.
# After the code intensively freeze, the release manager and report every found bug to the responsible developer. testers *test the code* thoroughly. If bugs are found, the developer who wrote the code is informed. The test include an acceptance test according to BSI-TR03124-2 testers and several other tests which are defined in the [[quality_management|Quality Management]] section of developer agree on who will be responsible for correcting the Wiki. The release phase is entered just if all problems occurred while testing are solved.
h2. Release Phase
bug (tester or developer). It should then be corrected in 2 working days.
# With the tests having been completed, the release manager *builds a release version* and distributes it to the users. A
# If a bug is detected in a release version does not mean that the final release is publish also manager and the project manager decide whether its correction will be included in the next regular release or a public beta or so *bug-fix release* is possible to ensure everything created. In the latter case, the release manager is working correctly because integration tests are mostly executed with test cards which may be different compared to production cards. This is especially necessary if the is support responsible for getting the bug corrected by the respective developer, getting the new cards included into a release. The status of version tested by the testers, building the bug-fix release may be determined by and distributing it to the version number. public.
The [[Software Lifecycle]] is documented in this wiki and a common work of all project participants
The *release versions* are numbered numered in accordance to "Semantic Versioning":http://semver.org/ which is basically the following scheme:
* The first digit is the major release, starting with 1. The project manager decides when this number should be increased.
* The second digit is the release count, starting with 0. It is increased with each release and reset to 0, when the major release number is increased.
* The third number is optional. It is only given to bug-fix releases, starting with 1.
* Prior to major releases, a -rcX suffix may be used to create public testing (beta test) releases.
* Between all releases, the version must be suffixed with -SNAPSHOT, so that the maven repository can distinguish distiguish release and development uploads.
h2. Post Release Phase
This is normally In addition to the point where [[code-style|code-style guidelines]] the process is restarted for the next major or minor release but there may project should furtheron be also the case that a critical bug what discovered which influences the security or stability of the software which creates the necessity carried out according to release a so called bugfix version. A bugfix release includes the same phases process model as a normal release but it addresses just the specific problem(s) which is/were the reason for the not planed release. described below.