# First Use

This article aims to help you understand the basic process of Erda and get started quickly by a demo case of software development life cycle.

# Preliminary Knowledge

Understand the operating mechanism and usage of container

Erda is a one-stop cloud native PaaS platform with its core as container. Mastering the operating mechanism and usage of container helps you better understand the platform design and operation.
Know the basic concepts of Java, such as Maven building and Java-based microservice deployment

The following will take a Java program as an example, and learn the basic concepts of Java in advance helps you get started quickly.
This article takes the following two microservices as examples. Please get the codes in advance for further use.
- Provider: Provide internal interface services (opens new window)
- Consumer: Provide services to the outside by the internal interface (opens new window)

# Installation

Erda supports installation in various ways:

Deploy via Docker Compose: Only suitable for trial environment without Kubernetes where you can get experience with Erda locally.
Minimal Mode Based on Helm: Suitable for scenarios where Erda is deployed in minimal mode on Kubernetes cluster.

erda.cloud (opens new window) is also available. Register an account and get started.

# Environment Preparation

Tips

If you have already joined a project, skip this chapter.

# Join an Organization

For self-built platform, log in to the admin account and create an organization.

Tips

If you do not have an admin account, please contact the platform admin.
For erda.cloud, log in to your account as a new user to create an organization.

Or choose public organizations to view detailed project information.

# Join a Project

Tips

Only the organization admin can create projects. Please confirm that you have the permissions of organization admin, or contact the organization admin.

Please go to Org Center > Projects > Add Project to create a project.

Tips

If you have no cluster, see Cluster Management to add one.

The subsequent operations mainly involve the two functions:

DevOps
- Collaboration
- Code hosting
- CI/CD
- API management
- Testing (including manual testing and automated testing)
Microservice governance
- Application monitoring
- API gateway
- Registration center & Configuration center

The following case will show the entire process and cover most functions. Before you start, please reconfirm that your project has sufficient cluster resources (approximately 2 core of CPU and 8 GB of memory are required). For details, see Cluster Management.

# Case of Software Development Life Cycle

Generally, the life cycle of a software project contains five stages listed below with the corresponding functions of Erda:

Requirement analysis: Collaboration
Architecture design: API management
Development: Code hosting + CI/CD
Quality assurance: Automated testing + Application monitoring (microservice governance)
Long-term operations: Microservice governance

This article will follow the process above and take a virtual customer case (a high-availability blog site) for demonstration:

Requirement analysis: Collaboration, including requirement collection, follow-up and realization
Development: Code hosting + CI/CD, including building, deployment and management
Quality assurance: Automated testing + Application monitoring (microservice governance)

# Requirement Analysis

Research and development is a set of activities that need collaboration of different roles. As the number of team members grows, collaboration systems or tools are required for working instead of verbal communication.

If you are an individual developer, it is also recommended that you read this chapter. Collaboration tools can not only solve the communication problems caused by team expansion, but also help developers effectively record and manage individual work.

For this case, complete the following steps:

Analyze and abstract requirements. Go to DevOps Platform > Projects > Project Collaboration > Requirement > New Requirement to add a requirement.

Generally, the product manager will complete the requirement information including its detailed description and acceptance criteria, etc.
The requirement is listed in Backlog initially and will be determined whether to be moved to Iteration by a review.

Assuming that the requirement has been reviewed and included in the 1.0 iteration.
The team leader will split the requirement into multiple tasks, which are related issues to the requirement.

Relate to Merge Request in tasks and bugs connect R&D and collaboration closer. For details, see Relation.

The project manager can see the efficiency and bottlenecks of collaboration by efficiency measure.

# Development

Tips

The architecture design mentioned in this case is only for reference.

Assuming that the team leader has finished the architecture design as follows:

Design two microservices Service and Web that communicate through Dubbo protocol, and use Zookeeper or other compatible registration center (such as Nacos).
Enable two instances for Server to ensure reliability.
Use MySQL for data storage and Redis for session and cache storage.

For this design, complete the following steps:

Go to DevOps Platform > App Center > App > Add Application to create two applications. For more information on applications, see Application Management.

After code pushing, create a pipeline.yml, which describes the CI/CD automation process. For details, see pipeline.yml.

Complete the CI part:

version: "1.1"

stages:
  - stage:
      - git-checkout:
  - stage:
      - buildpack:
          alias: blog-server
          params:
            context: ${git-checkout}
            modules:
              - name: service
                path: service
      - buildpack:
          alias: blog-web
          params:
            context: ${git-checkout}
            modules:
              - name: web
                path: web

Submit this file and then add a pipeline.

git add pipeline.yml
git commit -m 'add pipeline'
git push

Or just operate by the graphic interface without local pushing.

Complete the CD part:

version: "1.1"

stages:
  - stage:
      - git-checkout:
  - stage:
      - buildpack:
          alias: blog-server
          params:
            context: ${git-checkout}
            modules:
              - name: service
                path: service
      - buildpack:
          alias: blog-web
          params:
            context: ${git-checkout}
            modules:
              - name: web
                path: web
  - stage:
      - release:
          params:
            dice_yml: ${git-checkout}/dice.yml
            image:
              service: ${buildpack:OUTPUT:image-service}
              web: ${buildpack:OUTPUT:image-web}
  - stage:
      - deploy:
          params:
            release_id: ${release:OUTPUT:releaseID}

Two new steps of release and deploy are added above as well as a new file dice.yml. For details, see dice.yml.

Complete the file and submit the code.

services:
  web:
    ports:
      - 8095
    deployments:
      replicas: 1
    resources:
      cpu: 0.5
      mem: 512
      disk: 0
    expose:
      - 8095
  service:
    deployments:
      replicas: 1
    resources:
      cpu: 0.5
      mem: 512
      disk: 0
    ports:
      - 20880
    expose:
      - 20880
addons:
  mysql:
    plan: "mysql:basic"
    options:
      version: "5.7.23"
  redis:
    plan: "redis:basic"
    options:
      version: "3.2.12"

dice.yml needs to be deployed through a Docker image, which is missed above.

From the example of pipeline.yml, it can be found that the image is compiled during the CI process, as the code is compiled and packaged into a Docker image by buildpack, which is automatically inserted into dice.yml by release and be deployed based on the generated dice.yml.

Once the pipeline is executed successfully, you can view the released instances in deployments. For more information on O&M (such as restart, roll back, view logs), see Application Management.

# Quality Assurance

Quality assurance is involved in the whole R&D process, such as code review, automated testing, manual testing and regression testing. This article will introduce automated testing as an example. For details, see Code Quality.

Assuming that the functions are designed as follows:

Article list
Click the article to view details
Reads increases by one with one click

For this design, complete the following steps:

Go to DevOps Platform > Test Managent > Auto Test and create a scene set named Article.
Create a scene named Reads.
Add steps in the scene for orchestration.

When the software is released online, you can find and locate problems by tracing, log analysis and alarms, etc. For details, see Examples of Microservice Governance. This article only introduces the main features and application scenes briefly.

Go to the microservice platform to view the global topology of the project.

Tips

You can enter the microservice platform in the following ways:

Select Microservice Platform in the left menu bar.
Click Application Monitoring in deployments.

The global topology can be considered as the entry for daily O&M after the project goes online, from which you can see the traffic and loading. Click the red one to quickly go to the tracing list and locate the problem.

You can quickly find the exceptions and trace back to the cause in error analysis.

Each node represents a microservice and click the node for details.

← Concepts Configure Common Alarms for Machine →