Before proceeding with the onboarding process onto our platform, there are few preparatory steps you must complete. As a primary requirement, please ensure compliance with the guidelines outlined in the previous section titled Application Development . In essence, you should have a Dockerfile ready, a dedicated chart folder for the application’s objects, and another pipeline which houses our standard pipeline.

More about MBPM here

Lead metric as well such as dev onboarding time

However, to expedite the process and ensure adherence to best practices, we highly recommend the use of one of the pre-defined golden paths that our platform provides. For the purpose of this guide, we will be adopting a Node.js template sourced from our repository of golden paths.

We’ll do this manually first, for the sake of the learning experience and understanding. But in a later stage, this will be managed by our Backstage Internal Developer Portal.

Cloning the template

In this case, we’ll clone a real-time application framework with TypeScript and Node.js v18. It can interact with any backend technology, supports many databases out of the box and works with any frontend technology like React, VueJS, Angular, React Native, Android or iOS.

From the codespace root folder, fork and clone an example service-1 and inspect the folder structure.

cd /workspaces/workspace
gh repo fork dx-book/service-1 --org=$GITHUB_ORG --fork-name=service-1 --remote-name=upstream --clone

Here is simplified extract of what we get:

├── Dockerfile                -----> Required
├── README.md
├── chart                     -----> Required
├── pipeline                  -----> Required
├── config
│   └── default.json
├── package.json
├── public
│   └── index.html
├── src
│   ├── app.ts
│   ├── index.ts
│   ├── services
│   │   └── index.ts
├── test
│   └── app.test.ts
└── tsconfig.json

Service onboarding

The process of onboarding onto our platform is designed with simplicity in mind to ensure a seamless transition for development teams. This ease of onboarding is realized through a systematic approach in two steps.

1. Developers are expected to create a new GitHub repository or reuse an existing one. This repository should adhere to the specific file format guidelines endorsed by our platform. These guidelines require the inclusion of a Dockerfile, a chart folder, and a dedicated pipeline folder within the repository. An integral part of our platform’s operation is the automatic discovery of repositories, which significantly enhances the ease of this process.

2. The subsequent phase involves raising a Pull Request (PR) that targets the environments repository. The core objective of this step is the addition of a new file which is named according to your specific repository name, inclusive of essential metadata within the applications folder. For instance, one could create a file named environments/applications/service-1.yaml. An illustrative example of what the contents of this file should look like is as follows:

Since we now have a service-1 repository available, we must update the environments repository providing some more information about our service to the platform team for approval. The template for each new service is as follows:

cat > environments/applications/dev/service-1.yaml <<EOL
info:
  name: example
  team: platform
  product: workshop
  chart: 1.0.0
  version: 1.0.0
  revision: null
  custom: '{
    "extra": "field"
  }'
EOL

This essentially represents the various characteristics of your application, such as its name, the team responsible for it, the associated product, the chart version, and the image details. We’ll cover them in details later on.

Once the PR has been reviewed and approved by a member of the platform teams, it is then merged. This crucial approval triggers the commencement of the environment generation process. The mechanics of this process are discussed in further detail within the Generators section of our platform’s documentation.

In the example here, we’ll not create a PR, but push direct to the main branch instead. From the environments repository, run:

cd environments
git add applications/dev/service-1.yaml
git commit -m "Added details for service-1"
git push origin main

Through the execution of these steps, development teams can smoothly transition their projects onto our platform, promoting productivity and efficiency in their workflows. The platform is specifically engineered to facilitate this process, ensuring that teams can quickly adapt and start leveraging the various capabilities the platform offers.

By following these steps, the feature delivery team’s application can be seamlessly integrated into the platform and will adhere to the GitOps methodology, where the environments repository serves as the source of truth for all application configurations.

Certainly, this is automated in a future phase for greater efficiency and consistency using a IDP, for instance Backstage. However, to enhance the learning experience and provide a comprehensive understanding of the underlying mechanisms, we’re presently implementing these steps manually here.