Introduction

This document provides the general policy to be used at Recognize when developing software projects, of all sizes. It provides a standard and unified method of development and can be used as a reference.

Validity

This policy has been approved by Recognize management on February 23rd, 2021 and is valid from July 1st, 2021. It is possible that projects that started before this date do not apply to this policy. When in doubt, you can contact the Head of Development. All projects that started after July 1st, 2021 must follow this policy or have approval from the Head of Development to deviate from the policy (see: Deviations).

Version

You are currently viewing version 1.4.0 of this document. Please refer to this version of this policy within your projects by editing the recognize-policies.yaml file within the root of your project code repository.

# $schema: https://policy.recognize.nl/recognize-policies-schema.json

policies:
  security: 1.1.0
  development: 1.5.0
  privacy: 1.0.0
  testing: 1.0.0

Project Checklist

A checklist has been added at the end of this document so you can quickly check if your project is compliant with this policy. Please read the policy in full and make sure you complete understand it before using the checklist. This checklist has been created for your convenience and we do not guarantee that it fully covers everything within this policy.

Changelog

Version	Changes
1.0.0	First version
1.1.0	Added policy regarding repository structure
1.1.1	Allow GitHub for Continuous Integration
1.2.0	Migrate document to Markdown
1.3.0	Add policy for frameworks that have a strict mode
1.4.0	Add policy for Bitrise

Principles

The following principles apply to everything we do in software development and all the products that we create for our customers.

Automation

In everything we do, we maintain the DRY (Don't Repeat Yourself) principle. This can be while writing code, but we also automate tasks and mechanisms which are needed during software development. This can be building of the software, deploying, creating cloud resources, managing certificates etc.

This is not just because we want to save time in our work. We also maintain a consistent quality in the work that we do and do not create a dependency in so-called knowledge-holders ("only Bob knows how to do that").

Quality of our software

During development it is of utmost importance that everything that we release to a customer environment (e.g., production or acceptance):

Works as described
Delivers a great user experience
Is secure (see "Security policy")
Is properly tested (see "Testing policy")
Adheres to the architecture and other principles of the project

If we think, during development, that a release doesn't meet any of our requirements or we feel that quality is lacking, we do not release to a production environment.

Deviations

It is possible that during software development we want to deviate from the policy as stated here. This can be a one-time thing (perhaps the project has very specific needs that do not match with the policy stated here) or we decide we want to change our way of working and, as such, we need to change the policy.

In both cases you will need to contact the Head of Development. He can give one-time consent for a project (if the reasons are valid) or he can set a change of policy in motion.

Deviations from policy without consent of the Head of Development are not allowed. In case of a time-sensitive issue that requires a deviation from the policy, deviations are allowed, as long as they are reported to the Head of Development afterwards.

Consent for deviations will be recorded in the recognize-policies.yaml file. This can be done in two ways:

The Head of Development commits the deviation to the file
The team creates a pull request and requests a review from the Head of Development, who can approve the change and merge the pull request

# $schema: https://policy.recognize.nl/recognize-policies-schema.json

policies:
  development: 1.5.0

deviations:
- policy: development
  deviation: Lorem ipsum ...
  reason: Lorem ipsum ...