Guidelines for software development

This section contains guidelines for software development to be considered when developing a product for the EGI Federation.

Licensing

• Adopt an OSI-approved license; we recommend a business compatible license such as MIT or Apache 2.0
• The license should provide unlimited access rights to the EGI Community

Source code access

• Maintain the source code in a publicly-accessible software repository like GitHub
• You can request to use the EGI Federation GitHub organisation
  • If using another repository, a copy can be kept synchronized under the EGI Federation GitHub organisation
• All releases must be tagged appropriately

Code style

• Style guidelines must be defined and documented. A general style guide may be made available by EGI as a default.
• If you are extended an existing software component, then you must use the code style defined by the related product team
• If you are developing a new component, then you must use the code style practices for the programming language of your choice
• Code style compliance should be checked by automated means for every change

Best practices

• The industry best practices should be adopted
• As far as possible adopt 12 factor application pattern
• Configuration Management modules to deploy and configure the products should be provided and distributed through the corresponding distribution channels
  • Ansible is recommended, roles can be hosted under the EGI Federation organization in Ansible Galaxy

Security best practices

• Security best practices must be taken into account
• Security-related aspects must be considered from the beginning
• Security issues must be addressed in priority and following the EGI SVG recommendations and must take into account the points mentioned in the SVG Secure Coding and Software Security Checklist
• The Open Web Application Security Project (OWASP) provides extensive documentation, standards (such as ASVS) and tools to ensure that your software has capabilities to defend against common attacks.

Suggested material and references

• Microsoft® Open Source Software (OSS) Secure Supply Chain (SSC) Framework Simplified Requirements
• Secure Software Development Framework | CSRC
• NIST: Cybersecurity
• Cybersecurity & Infrastructure Security Agency
• Microsoft Security Development Lifecycle (SDL)
• Introduction to Software Security (video course by Trusted CI, WISC, UAB)

Tooling and telemetry

• If the project is an application or an infrastructure component, it should follow as close as possible the monitoring guidelines set by the Site Reliability Engineer book

Testing

• Unit tests should be provided
• Unit testing should be automated
• Code coverage should be computed as part of the continuous integration
• When possible functional and integration tests should be automated
• If it’s not possible for some components the product team should provide report about those tests for the new releases

Code Review

• A team of code reviewers shall be specified for each project
• Changes must be reviewed by the code review team prior to be merged using a Pull Request-like workflow

Documentation

• Documentation must be treated like code
  • Written in a plain text-based format
  • Management in a repository and versioning
  • Markdown and reStructuredText formats are recommended
• The documentation for an EGI Service should be submitted for publishing on the EGI Documentation site using the related GitHub repository
• A “Community First” approach should be followed
  • Contributing, onboarding and community guidelines should be available from the start of the project
• Documentation should be available for
  • Developers
  • Administrators (Deployment and administration)
  • End users

Artefacts Release and delivery

• Artefacts should be tagged according to Semantic Versioning or to Calendar Versioning that can be more appropriate for OS images
• Artefacts should have a DOI and associated short writeup (see Documentation above)
• Artefacts should be published in publicly available repositories
  • EGI Application Database can be used for this
  • UMD can be used to distribute middleware components
• It should be possible to automatically build production-grade distribution artefacts from the repository using provided build scripts and files
• Where appropriate, native packages for EGI Federation-supported Operating System should be provided:
  • CentOS 7 (rpm)
  • Ubuntu 20.04 LTS (deb)
• Containers are accepted
  • Containers must be compatible with EGI Cloud services

Request for information

You can ask for more information about them by contacting us via our site.