DRAFT FOR COMMENT FROM THE WORKING TEAM
Introduction
The LFN Technical Community is critically dependent on its software development tool chain for success. The standard tool chain today is Gerrit for Source Code Management (SCM) , Jenkins for Continuous Integration / Continuous Deliver (CI/CD) and Nexus for artifact repositories.
...
Hardware Hosting technologies have also modernized in recent year as bare metal public cloud has been emerging. While it is anticipated that there will always be some magic hardware, there are new opportunities that may dramatically reduce the amount/costs while improving the reliability of services.
Summarized Results
SCM
GitHub and GitLab are the dominant tools for SCM that satisfy the requirement of easy to use and popular. There are many choices but either of these would be good. Bit Bucket Bitbucket is also very popular but is more commercially oriented. GitLab has a slight edge since it can also be run in corporate environment behind the firewall and meet corporate community developer requirements with a consistent GIT git history.
CI/CD
CircleCI for GitHub and GitLab-CI are the dominant tools that are most compatible with their respective SCM systems. There are more options in this space than SCM and it personal project bias might influence a project to use either CircleCI or GitLab-CI
Artifact Repository
DockerHub Docker Hub was the preferred docker repository hands down. Many projects are already moving to dockerhub Docker Hub for the released containers.
Packagecloud.io provides apt/yum/maven repos as a service. FD.io is in the process of switching to it for apt/yum, and has had very happy experiences with it.
...
This recommendation is provided to the Technology Advisory Council for communication to the projects within Linux Foundation Networking. No specific implementation plans are included, just recommendations.
The default preferred path for new generic software projects that do not have a dependency on non-standard hardware resources and/or gerrit for legacy code is to use a pull model based SCM.DRAFT FOR DISCUSSION AT THE INFRASTRUCTURE WORKING GROUP -DOES NOT REPRESENT CONSENSUS
For all hosted solutions we recommend:
Github -> CircleCI -> Packagecloud
Some projects may need premises versions for compatibility with corporate build environments
Gitlab -> Gitlab-CI -> Packagecloud
For legacy projects and those who need Gerrit for legacy code (C/C++) then we recommend:
Gerrit -> Jenkins -> Nexus
If non-standard hardware resources are required in addition:
Github -> CircleCI (for normal jobs) -> Packet ( several possible launching methods including terraform) -> Packagecloud
If even more specialized hardware is needed:
Github -> CircleCI -> Packagecloud
-> drone.io server launching on nomadproject.io cluster ^
The above tool chains have been used and work.
As projects move onto a new tool chain, LF business agreements are established with them and LF and the community develops more expertise with a preferred workflow then a specific path will be more clear.
Should the TAC recommend to member projects that they move off Gerrit/Jenkins/Nexus and onto a new tool chain ?
- For new LFN Projects we would recommend "As a Service" infrastructure whether Github ecosystem + CI as a Service (Circle CI/Drone.io/Azure Pipelines/Host Tekron Tekton) or all in one GitLab/GitLab-CI as the going forward tool chain for SCM, CI/CD and Docker Hub for artifacts.
- For existing LFN Projects we would recommend moving to "As a Service" infrastructure whether Github ecosystem + CI as a Service (Circle CI/Drone.io/Azure Pipelines/Host TekronTekton) or all in one GitLab/GitLab-CI if they are considering a new tool chain or to take advantage of the "As A Service" options.
- For magic hardware it is anticipated that "As a Service" CI can adequately drive activities on that hardware. New projects should plan to use "As a Service" CI for managing any special hardware. Existing projects may chose to use As a Service if it fits their process/needs.
Existing projects could choose to move or not.
...
The working group believes that moving to a "As A Service" model will result in better costs structure. LF should start a project to get a business case together and analyze what cost savings could be achieved by moving to a GitLab/GitLab-CI as a service model.
For Discussion
- Community managable manageable and controllable.
Contributors
...