A consequence of the dominance of Git in the market is that the majority of development tools have excellent support for it as a version control system, either built-in or available as a plugin. Regarding the tools selected to be reused by SmartCLIDE, Eclipse Theia includes built-in git support, while workflows defined in jBPM are stored internally in Git and can be synchronized to an external Git repository.
While Git on its own provides excellent support for version control, there are several services that provide additional functionality on top, including GitHub, GitLab, and Atlassian Bitbucket. Some common additional features are:
- A web-based user interface to support git repository configuration as well as other value-added services
- Support for code review
- Support for CI/CD pipelines
For SmartCLIDE, the consortium has chosen to use GitLab since it is available as a pre-packaged Docker image that can be deployed either on-premises or in the cloud and has a number of other features that make it useful for integration in the SmartCLIDE environment, such as:
- Integration with external security providers for access management, and Keycloak in particular, which is the chosen User Access Management platform
- RESTful and GraphQL APIs that can be used by other components of SmartCLIDE
- Native support for CI/CD
- Hierarchical organisation of Git repositories using “Groups” and “Subgroups”
As a proposed structure, the top-level SmartCLIDE group contains sub-groups named “Services” and “Workflows”, each of which contains GitLab projects that contain a Git Repository plus other data for handling additional features such as merge requests and CI/CD.
There are a number of source-code artifacts required to implement a workflow in the SmartCLIDE environment, which should all be version-controlled:
- Workflow definitions and metadata: Each workflow definition has its own repository on the GitLab server. Data stored in version control for the workflow includes:
- Metadata regarding the workflow (e.g., name, description, and service dependencies)
- Gherkin description of the workflow
- BPMN model of the workflow.
- Service Source Code: In cases where a service is written from scratch, assembled using a template, or otherwise modified from existing source code, the service should have its own Git repository on the GitLab server. It is proposed to build a library of service definitions, grouped separately from the workflow definitions, since each service has the potential to be re-used in different workflows.
If you wish to learn more about this aspect of the SmartCLIDE project, we invite you to read the public deliverable entitled “D3.1 – Early SmartCLIDE Cloud IDE Design“.
No responses yet