Open eCard

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. 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. 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

In this phase the developers implement the features or solve the bugs according to their assigned tasks. Features have to be implemented until the feature freeze date else the feature will be rejected and is part of the next release. After the feature freeze it is just allowed to commit fixes for existing code. While 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* should be uploaded to the repository. This means the application still builds with the commit, the overall change is explainable in one sentence (commit log), the commit shall be as small as possible and it should be reversible without breaking the software. When changing shared functionality this is certainly not true.

# *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 the development phase lasts until the feature freeze which also is the entry point for the test phase.

h2. Test Phase

During this phase the manager and the tester test the code intensively and report every found bug to the responsible developer. The test include an acceptance test according to BSI-TR03124-2 and several other tests which are defined in the [[quality_management|Quality Management]] section of the Wiki. The release phase is entered just if all problems occurred while testing are solved.

h2. Release Phase

With the tests having been completed, the release manager *builds a release version* and distributes it to the users. A release version does not mean that the final release is publish also a public beta or so is possible to ensure everything 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 for new cards included into a release. The status of the release may be determined by the version number.

The *release versions* are numbered 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 release and development uploads.

h2. Post Release Phase

This is normally the point where the process is restarted for the next major or minor release but there may be also the case that a critical bug what discovered which influences the security or stability of the software which creates the necessity to release a so called bugfix version. A bugfix release includes the same phases as a normal release but it addresses just the specific problem(s) which is/were the reason for the not planed release.