Page tree
Skip to end of metadata
Go to start of metadata

The Symphony Software Foundation provides a service-based infrastructure to support committers throughout the entire project lifecycle.

This page helps project leads (or any other project member) to setup a project pipeline for software development following the team's preferences and leveraging the infrastructure provided by the Foundation.


When the code transfer is completed, a new project will be publicly hosted in the Foundation’s Github Organisation, granting write access to project team members.

github project page

To know more about Github, you can browse through their list of guides.

Issue tracking

Managing issues (or tickets) across a team is a very important project activity, especially at the beginning; the Foundation strongly advises to choose and setup an issue tracking system as soon as the project is transferred.

Github Issues is available for all hosted projects; alternatively, the project team can request the Foundation to host the project on the JIRA Foundation instance, by simply creating an INFRA Task issue.

github issues page

Additional configuration tasks for issue tracking include:

  • Define a taxonomy of issue labels (i.e. Bug, Enhancement, Question, Task, ...)
  • Define an initial list of milestones

Follow the Mastering Issues documentation page to get started in 10 minutes.


When setting up the software development process, there are different common configuration steps that the team need to take care of; below are listed the most important ones, linking to the specific pages that describe the infrastructure configuration depending on the language and eco-system of choice.

Building and testing

The build is an end-to-end process that converts source code into reusable artifacts, something that we will refer to as deployable units, which is developed by the project team and hosted in the github repository. It is a particularly important task, as it can centralise and trigger several automated sub-tasks, such as version control, code testing, quality and compliance reports and more.

A working build process is key to implement more automated processes, such as release, Continuous Integration and automated deployments; it is also a requirement for project activation.

To know more about build configuration, check the Languages page.

Version control

Version control is the process to establish a format to a project version and the rules to update it, preferably integrating with automated build and release systems; the Foundation mandates the user of Semantic Versioning ("semver") throughout a project's lifecycle:

  • for incubating projects, it is allowed to deploy releases with version numbers < 1.0.0
  • for active projects, it is allowed to deploy releases with version 1.0.0 and above

Every project team is encouraged to define more specific MAJOR, MINOR and PATCH definitions, in order to provide a better understanding for consumers on what to expect when adopted; for those ecosystems that support more complex version number representations (e.g. Python), the Foundation strongly recommends restricting version numbers to semver format wherever possible.


As part of the activation process, the Foundation requires several documentation items, to make sure that the release of an active project complies with high documentation standards.

There are different ways documentation can be written and published; the easiest (and most visible), is to use Markdown files hosted on Github (i.e.; additionally, you can

Some languages or build systems provide support for automated documentation publishing; browse the Languages page to know more about automated configurations for a given language.


The release process allows to publish deployable units into a publicly available artifact repository, by invoking the build process and applying version control to increment the project's version; the Foundation collects guides and best practices on how to release a project, depending on the language and eco-system of choice; browse the Languages page to know more about automated configurations for a given language.

Continuous Integration (CI)

CI allows to automatically verify every code change that allows to detect problems earlier; you can read more here; the Foundation facilitates the configuration of CI systems, depending of the language and eco-system of choice.

The Foundation does not mandate CI at any project phase, though it strongly advises to investigate automating any process that can improve software quality, security and compliance.


In order to measure and report the level of quality, security and legal compliance, the Foundation facilitates the integration of build processes with external systems specialised in code analysis; the Reporting page also guides a project team on how to produce and publish measurements that are required by project activation.

See More

  • No labels