Development process - PRD-DEV-001

All our developments fall in one of the following categories.

Projects progress are discussed during our monthly team meetings and tracked in meeting notes.

Document references

• standard: ISO 9001:2015
• quality document

Terms

• kanboard: https://gitlab.inria.fr/genouest/qualite-genouest/-/issues/

Project types

Research and development

R&D are internal developments, targeting internal needs (though software could be used by a wider audience)

Projects:

• are open source by default and should be published in our public repositories. If for any reason project should be private, it must be discussed during one of our regular meetings.
• have a license: Affero-GPL / Apache 2.0 / MIT
• have an entry in our kanboard for each project with label processus/R&D and a status label
• follow our R&D development workflow

Collaboration

Those projects relate to collaboration requests where we are involved in developments of a larger project, involving external or internal partners. Partner may be involved in development or not (only providing requirements, existing software, data, etc.)

Projects:

• have an entry in our kanboard for each project with label processus/R&D and a status label,
• have an entry in Cesgo, tagged as R&D, for project follow-up and collaboration if any collaboration is needed and must be kept private, or managed via github directly in case of public project
• have a license: to be decided with partners
• follow our development workflow

Web interface

Those projects relate to external or internal partners requesting the development of a basic development. By basic, we mean projects requesting only a few days of work.

Projects:

• are private and in git repo private repositories
• do not have a license usually
• follow our light development workflow

Workflow

Project follow-up/planification

Project go/no-go (at the start or during project) is discussed during team monthly meetings along major issues/decisions to take.

Cesgo will track high level planning of the project and partners interactions (if any is needed), while github/gitlab will be used for planning (issues/features/milestones)

R&D

• project is declared in kanboard
• use of Github (public projects) or INRIA Gitlab infrastructure (private projects, R&D group) for code, issues tracking and planification. An entry must be created in gitlab/genouest/r-d (with a link to the github repository if project is managed there). Projects must have an issue in gitlab/r-d titled status with at least labels project::xx and status/xxx
• track all major project events in gitlab repository wiki:
• project goal
• organisation
• project time contraints if applicable
• deployment in production
• etc.
• if project is linked to a contract, add contract information in the wiki
• requirements:
• contains a README and LICENSE file
• provides INSTALL instructions (may be in README)
• has documentation
• provides unit tests and continuous integration if applicable, else a test procedure must be provided
• if possible, provides Docker images
• if applicable, software is scalable (multi machine)
• project management:
• use agile mode with regular release (~monthly basis)
• features and bugs are managed via issues and assigned to milestones

A final report will be created to evaluate management and technology issues and project state (go to production, orphan, etc.).

When in production, one must contact a system administrator to add backups and check security requirements.

Development

• customer requests for a new project with an helpesk support email
• meeting with the customer (with a license choice)
• project is approved during our team meetings
• project is added to the kanboard
• use of Github (public projects) or INRIA Gitlab infrastructure (private projects, R&D group) for code, issues tracking and planification. An entry must be created in gitlab/genouest/r-d (with a link to the github repository if project is managed there). Projects must have an issue in gitlab/r-d titled status with at least labels project::xx and status/xxx
• tracks all main project events with a link to the request ticket in projet wiki
• ticket link
• project goal
• partners involved and role
• high level planning
• organization
• project documents during the life of the project (specifications etc.)
• project updates, customer interactions
• project requirements:
• specifications:
  • customer provides an input specification, specification can be written by our team after the meeting and validated by the customer
  • includes a global planning with deliverables/milestones
  • who and how the project will be tested
  • agree on project follow-up schedule
  • agree on regular releases for testing and validation
  • role of involved people in projects
• documentation: user doc, install doc, test doc (according to the project)
• end of project:
  • meeting with customer (may be mail only)
  • provide a document to be validated by the customer specifying the final deliverables
• satisfaction form
• project management:
• use agile mode with regular release (~monthly basis)
• features and bugs are managed via issues and assigned to milestones
• project internal follow-up is done on monthly basis during team meetings
• project follow-up with customer is done on predefined basis during team meetings
• additional requirements:
• contains a README and LICENSE file
• provides INSTALL instructions (may be in README)
• has documentation
• provides unit tests and continuous integration
• if possible, provides Docker images
• if applicable, software is scalable (multi machine)

If software is put in production in our infrastructure, one must contact a system administrator to add backups and check for security requirements.

Light

• customer requests for a new project with an helpesk support email
• meeting with the customer
• project is approved during our meetings
• customer provides an input specification
• Specification can be written by our team after the meeting and validated by the customer
• use of git in Github or INRIA Gitlab infrastructure (in any case, an entry in gitlab/genouest/r&d must be created linked to external repo and link to original ticket)
• provides INSTALL instructions
• if possible, provides Docker images
• customer validates software and approval is registered via the helpdesk ticket
• if not approved, track info in support email and agree needed updates and planning
• customer sends the satisfaction form

Development constraints

There is no language constraints but Python, Node and Go are default choices.

If using Python, Python 3 must be used.

Docker should be used by default. Application should provide kubernetes recipes.

Commonly used frameworks:

• Node: Express
• Python: Pyramid/Flask
• Web: React, VueJS

Web applications must be minified for production.

Deploying in our infrastructure

All our servers are Linux based x86_64, so final application should only target this architecture. Software may target other archs/OS but this is not mandatory.

If not using Docker, software must run on CentOS 8, our current operating system.

Our infrastructure provides shared directories between servers, they can be used to share files for scalability or multi-component share.

Web accesses are restricted, all web servers communication must go through our web proxy.

Applications should not run as root but as unprivileged user.

In case of authentication, software must use our LDAP server if applicable. Elixir AAI can be used for a broader audience, allowing Elixir community to use our tools.