DMA Tech

Development process
High-level development process, release and change management

Euro Business Parc www.dma-tech.com

23, Gen. Gheorghe Mardarescu Street info@dma-tech.com

410605, Oradea, RO (0040) 734 580 793

DMA Tech - Development Process 2

Table of contents

1. Project Setup
1.1 Metrics
1.2 Coding Standards
1.3 Source control management and commit policies
1.4. Code review
1.5. Best practices
1.6. Tools

2. Continuous Integration
2.1. Environments description
2.2. Pipeline
2.3. Tools

3. Secure software development

3.1 Security strategies
3.2 Tools

4. Definition of done

5. Deployment
5.1. Configuration management tools
5.2. Automated deployment tools

6. Release strategy
6.1. Versioning policy
6.2. Release notes

7. Integration and acceptance testing

8. Documentation
8.1. User manual
8.2. Software design document
8.3. Test plan
8.4. API documentation
8.5. Tools

9. Change management
 DMA Tech - Development Process 3

1. Project setup
!

1.1. Metrics

Metric Value

Unit test coverage Over 80%

Cyclomatic complexity Under 10

Package tangle Under 5%

1.2. Coding standards

The following coding standards will be used during the development process:

Pollution of test classes

Create Factory classes for the given objects.
Create interfaces for controllers
Interfaces for controllers will add a layer of separation of the API definition and the
actual implementation.
Complex logic in controllers
Complex workflows in controllers should be integrated in service layer.
Mappers/converters
Low level of test coverage, error prone converters.
Possibility to add annotation processor mappers to eliminate boilerplate code.
Create multiple methods in a mapper, rather than 1 class per mapper.
Service class size
Enforce single responsibility principle to reduce the size of the service classes.
Extract specific logic (Validators, Providers, Strategies) into different classes.
Method length
Method length will not be over 25 lines
Line length
140 characters
 DMA Tech - Development Process 6

1.3. Source control management and commit policies

The proposed SCM workflow is gitflow.

Code base
Master branch for released code
Develop branch used for merged features
Release branch for release candidates
Hotfix branch for immediate/urgent fixes in master code
Commit policies
The Jira ticket will be present in the commit comment, so it can be referenced in
release notes.
Bitbucket
DMA Tech Bitbucket will be used
All developers will be granted access to bitbucket
DMA Tech - Development Process !

1.4. Code review

Code reviews are public, all developers can and should do code review.
Rely on developer responsibility, features will be merged when at least two other developers
have reviewed the code.
Focus mainly on improving the static code quality
Respecting best practices
Respecting code standards
Provide unit and integration tests with respectable coverage;
Possibility to review work in progress (WIP)
Avoid reviewing important design decisions only at the end of development
Important design decisions should be documented
Summary for what to look for in a code review
Focus on respecting all described in this document.
 DMA Tech - Development Process 8

1.5. Best practices

Package naming conventions:
"com."business"."application"."functional module"."layer
level" Usage example :
* A service: com.dma.user.service

Class naming conventions:

Spring Data Repository interfaces are suffixed like xxxRepository.java
DAO implementations are suffixed like xxxRepositoryImpl.java
Service interfaces (if relevant) and interfaceless service implementations are suffixed
like xxxService.java
Service implementations (with interface present) are suffixed like xxxServiceImpl.java

Internal and external model:

Internal model is the model which is used within the service. It can be stored in a database and
will be used by services for all business rules. The internal model is unique to the service
External models are representations of the model for communication with external services
As producer, the external model usually mimics the internal model in some ways.
However, the external model classes (including enums !) must always be different
than the internal model.
As consumer, the external model is usually the same model as the exposed service it
is consuming as a client.
REST endpoints
Sample context : there are notifications for a user. Any resource used in the uri must be used with
its plural. These are the endpoints we should create for this use case :
GET /users
Get the user list
POST /users
Create a new user
PUT /users/{userId}
Update an existing user
GET /users/{userId}/notifications
Get the notifications of a given user
POST /users/{userId}/notifications
Create a new notification for the given user
GET /notifications/{notificationId}
Get notification details by its id
PUT /notifications/{notificationId}
Update a given notification
 DMA Tech - Development Process ! 9

1.6. Tools
Static code analysis will be performed with the following tools. This process will be a part of the
continuous integration process.

Checkstyle

Process already in place for the projects.

Unit test / Integration test
Jacoco plugin to generate unit test reports.
Test coverage should have a respectable coverage. 80% is considered a
respectable coverage and the aim is to improve the project to surpass this limit.
Classes which have to be unit tested (JUnit):
Aggregates
Mappers
Services
Any other class that contains logic
Integration tests should be written for (SoapUI):
Controllers/Resources
Sonar
Measure static code quality
Technical debt
Tests coverage
Code duplication
Complexity per method
Package tangle
Security issues
A step that takes place in the transition from the DEV and VALID environments
FindBugs
 DMA Tech - Development Process ! 10

2. Continuous Integration
2.1. Environments description

Proposed solution:
1 dev environment in which reviewed features are integrated.
Demo for integrating tested features from dev environment
PreProduction should be closest to production, to be used for pre validating features to release.

2.2. Pipeline

2.3. Tools
Jenkins
Maven
Nexus
Sonar
DMA Tech - Development Process ! 11

3. Secure software development

3.1 Security strategies
OWASP top 10 compliance
Quarterly security audits
Application security reports delivered from certified 3rd party

3.2 Tools
SSLLabs
OWASP Zed Attack Proxy (ZAP)

4. Definition of done
Code is written
Unit tests are written for business logic code
Code is reviewed by other developers
Important architecture decisions are documented
Feature is checked by developer on staging (DEV)
Feature is checked by QA member on staging (DEV)
 DMA Tech - Development Process ! 12

5. Deployment
5.1. Configuration management tools
For environment configuration we use Ansible. This allows us to automate the server configuration
and provisioning.

5.2. Automated deployment tools

For automated application deployment we use Ansible. With Ansible we can handle large scale
deployments in a safe and reliable way.
 DMA Tech - Development Process ! 13

6. Release strategy
6.1. Versioning policy
Versioning policy to be defined. Versions should be defined at project level. The mobile application
should be aware of API versions.
Release strategy:
Provide release notes containing released features.
Release plan to guarantee service availability and backwards compatibility

6.2 Release notes

Release notes may include the following sections:
Header Document Name (i.e. Release Notes), product name, release number, release
date, note date, note version, etc.
Overview - A brief overview of the product and changes
Purpose - A brief overview of the purpose of the release note with a listing of what is new
in this release, including bug fixesand new features.
Issue Summary - A short description of the bug or the enhancement in the release.
Steps to Reproduce - The steps that were followed when the bug was encountered.
Resolution - A short description of the modification/enhancement that was made to fix the
bug.
End-User Impact - What different actions are needed by the end-users of the application.
This should include whether other functionality is impacted by these changes.
Support Impacts - Changes required in the daily process of administering the software.
Notes - Notes about software or hardware installation, upgrades and product
documentation (including documentation updates)
DMA Tech - Development Process ! 14

7. Integration and acceptance testing

Setup integration environments.
Test integration with 3rd party services
Test End to End scenarios
Integrate integration and acceptance tests in the CI pipeline
Tools:
SoapUI
Selenium
QA approach
Provided by DMA Tech.
DMA Tech QA will validate features for release.
Automation testing project started.
 DMA Tech - Development Process ! 15

8. Documentation
8.1. User manual
The user manual delivered with the project will have the following contents:
A guide on how to use the main function of the system
A troubleshooting section detailing possible errors or problems that may occur, along with how
to fix them
A FAQ (Frequently Asked Questions)
Where to find further help, and contact details
A glossary

8.2. Software design document

This document covers the following aspects of the technical documentation:
Data design (attributes and relationships between data objects)
The architecture design (information flowing characteristics, program structure, boundaries
between incoming and outgoing data)
The interface design (internal and external program interfaces)
The procedural design

8.3. Test plan

The test plan is the document that defines the entire QA process. It will contain detailed explanation
of things like:
Test strategy (objectives, assumptions, principles, data approach, types and levels of testing,
deliverables, tools & technologies)
Execution strategy (entry and exit criteria, defect management, metrics, defect tracking and
reporting)
Test management process (management tool, design approach, risks and mitigation factors,
role expectations)
Test environment
 DMA Tech - Development Process ! 16

8.4. API documentation

The REST API will be documented based on the Open API Initiative recommendations. The purpose
is to define a standard, language-agnostic interface to REST APIs which allows both humans and
computers to discover and understand the capabilities of the service without access to source code,
documentation, or through network traffic inspection. When properly defined, a consumer can
understand and interact with the remote service with a minimal amount of implementation logic.

8.5. Tools
Confluence
Swagger
 DMA Tech - Development Process ! 17

9. Change management
We define the change management as following:

Change management ensures that:

Changes are discovered and recorded
An assessment is made on the impact, cost, benefit and risk of proposed changes
The business justification are identified and approval is obtained
Change implementation is managed and coordinated, which is then monitored and reported
Change requests are then reviewed and closed
 !

Thank you!

www.dma-tech.com