Development process

We divide the work into tasks in such a way that they can always be put into production at the end of the job.

We use one base code for all Our Clients.

We build code agnostic to acquier and processor settings.

We use git-flow - Gitflow Workflow | Atlassian Git Tutorial

Develop, master are protected branches

We treat develop as always ready to deploy for production

1. only tasks after tests

2. only tasks after review

3. QA tests on feature branches.

For hot-fix we use git-flow hot-fix - hotfix from master

We do not use catalog feature/.

We do not create release branches

Every task has his own feature branch that name starts with task id e.x. CPD-652

We use release plugin in every project besides library.

We use squash commits when we merge feature branch into develop.

TODO - a task that nobody took.

IN PROGRESS - a task assigned to one of AP RS developers.

1. create branch for task CPD-[0-9]+

2. Every commit need to start with task ID and summary

REVIEW - a task that development ended also documentation changes.

1. Create Merge request to develop in Git Lab

2. Inform about review on chat Card processing - scrum team

3. AP RS does the review fixes.

DONE (column TESTING)- Tasks testing on the Fenige side after the code is merged and built on the Test environment.

1. Testing by Fenige

   1. Automatization adds a link to the review portal.

2. Testing by AP SA - QA Team

   1. manual testing - if the requirement is only to manually check (e.g. firing up the majk tool) that the functionality is working correctly, it is sufficient that the task previously assigned to the developer is moved to the column TESTING and assigned to @Maciej Szymański / @Katarzyna Zmyslowska,

   2. automated tests - if changes need to be made to the majk tool code or new things need to be added to it, a completely new task should be issued for testing with the type IMPROVEMENT/NEW FEATURE (requirements under KUP). This task should also be placed in the TESTING column and can be immediately assigned to @Maciej Szymański / @Katarzyna Zmyslowska .

   3. DESCRIPTION:

      1. in the description of each task there should be a precise description of the functionality that has been prepared, what it concerns and what will be achieved by its implementation,

      2. in the description for automated tests and in the commentary for manual tests there should also be information about the steps to be taken in order to test the functionality, together with information about the expected result. If the task requires entering/using certain data during the test, such information should also be provided.

      3. it is important that the descriptions should be as precise as possible (a link to a wiki is unfortunately not always sufficient)

      4. it is useful to indicate the deadline for the test

CLOSED - then it automatically attach to the open Release. And this version of application is deploy on staging.

CLOSED - it is tracked with releases.

1. Setting a date for production release by the Fenige with BM and sending an email to Blue Media.

2. Production release by the Fenige.

3. Notification when the production drop-in is completed - email to Autopay and notifications on Teams chat - [Fenige+APRS] Card processing.

4. AP RS close release and automatization create a new one.