The PHYSICS project aims to improve and extend the Function-as-a-service model paradigm. In order to achieve this goal it is not only necessary to develop and integrate different components with each other, but there is also a clear need to do it in an agile way with the involvement of several partners.
The first relevant choice made by the PHYSICS team to achieve this goal was to follow an agile development methodology, which various partners can leverage to develop, deploy and test their own components seamlessly from the edge to the cloud.
The implication of this method has been incorporated into the paradigm of DevOps[1], based on the CI/CD (Continuous Integration/Continuous Delivery) pipeline concept. The use of such pipelines is particularly suitable in PHYSICS, since it has been conceived and designed in a cloud-native perspective, therefore with the leverage of container-based microservices architectures.
[1] https://www.gartner.com/en/information-technology/glossary/devops
The second major choice that has been done by the team was to found the orchestration of these containers on what is the de-facto market standard on this topic, namely Kubernetes[1].
In such technological context, a development environment based on OKD[2] has been created, where the tools for the implementation of the CI/CD have been installed within an isolated environment (namespace). The selected tools are:
- Gitlab[3], a Git repository manager that lets developer teams collaborate on PHYSICS’s source code.
- Jenkins[4], the de-facto standard open-source automation server for orchestrating CI/CD workflows.
- Harbor[5], a popular CNCF compliant Docker registry.
- OpenLDAP[6], used as the single user directory for all tools, centralising authentication and simplifying management of developer accounts.
[1] https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
[2] https://www.okd.io/#what-is-okd
[3] Gitlab (https://about.gitlab.com/solutions/agile-delivery/)
[4] Jenkins (https://www.jenkins.io/doc/)
[5] Harbor (https://goharbor.io/docs/2.3.0/install-config/)
[6] OpenLDAP (https://www.openldap.org/doc/admin25/)
The interaction between such tools and the complete actual process and steps to be followed by a project development partner is shown the picture below:
Starting from step #1, when a developer pushes a new component code, Gogs invokes through a webhook a pipeline (also referred as job) configured inside Jenkins. The job builds the component, runs unit tests and, if everything has worked in a proper way, builds an updated Docker image that is pushed to Harbor. The following step deploys the updated component in the specific namespace: in fact, we have as many namespaces as the WPs (Work Packages number.
At the end of the process, Jenkins sends a notification to a dedicated CI/CD channel on the PHYSICS Slack[1] workspace, so that developers are informed that a new build occurred and whether it was successful or not. This is just a preview of what has been done in PHYSICS to create a unified development, test and deployment environment for the PHYSICS solution framework: further challenges and enhancements are ongoing, so stay tuned!
[1] Slack (https://slack.com/intl/en-pt/features)
