In indyco, the necessary functionalities for project life cycle management have been implemented in a complex ecosystem
These features refer to the main methodologies that we find in the literature and aim at creating an environment where software design, testing and release can take place quickly, frequently and independently.
In particular, in the summary table below we can find the phases covered by indyco through its respective functions.
Phase | Synonims | Indyco Feature |
Production | Sprint, Iteration, Development | Version Control |
Closing | Shipping, release, deploy | Publish |
Both features have different life cycles and users.
Version control
The versioning feature is a powerful collaboration tool as it allows multiple people to work on the same project at the same time. It also offers the possibility to keep track of changes which have been made through a real history of the project evolution.
The main users of versioning are the developers of the project, who will be free and independent to carry out features or changes to the current project through the commit feature, without altering the published project. The development of the project takes place daily and, consequently, the phase of versioning, too. This way the developers are sure not to miss the local changes and the project is always shared and updated within the team.
Publish
The publishing feature on indyco Explorer allows to view the project through the browser without the possibility of submitting changes and is therefore suitable for business users. This functionality can be understood as an interactive documentation of the project.
The person in charge of publishing will be the project approver, who, once confirmed and validated any changes, through the publishing feature, will update the visualization for business users; this operation is typically done at the same time as the release of new features in the entire analytical ecosystem of data fruition.
There are very often different analytical environments such as production, quality and testing.
In the same way it is possible to publish in the various environments the respective "photograph" corresponding to the version currently in use.
The other way around, the versioning control system mentioned in the previous paragraph is unique in the company ecosystem.
Published Versions
If version control is the historical memory of the design evolution, publishing is the element that makes the version currently in use in that environment available to users.
Each publication virtually replaces the previous one that has become "obsolete", and therefore no longer relevant.
However, in real cases of design the need to keep track of the versions that have been previously published has emerged, mainly to manage rollback in case it is necessary to carry out a timely restoration of the previous state.
Indyco displays the history of the published versions and allows to promote to publication again a previously published version.
Best practices
In the indyco ecosystem, the development and release moments are respectively covered by the version control and the deploy functionalities, which are distinct but complementary.
Within indyco server you can selectively assign permissions to the relevant functionality: typically version control is enabled for developers while a subset of them has the rights to publish.
We recommend that the published version always corresponds to a specific commit, and that the publication of local projects is avoided in case the project is under version control.