Help Center/ CodeArts/ Best Practices/ Huawei E2E (HE2E) DevOps Practice/ Procedure/ Step 5: Building an Application
Updated on 2023-12-08 GMT+08:00
View PDF

Step 5: Building an Application

CodeArts Build provides a hybrid language build platform with simple configurations, supports one-click task creation, configuration, and execution, and automates activities such as code obtaining, building, and packaging.

This section describes how Chris, a developer, builds environment images, compiles and packages code into software packages, and triggers automatic building through code changes to implement continuous integration.

Introduction to Preset Tasks

There are five build tasks preset in the sample project.

Table 1 Preset tasks

Preset Task

Description

phoenix-sample-ci

Basic build task

phoenix-sample-ci-test

Task for building available images in the test environment

phoenix-sample-ci-worker

Task for creating a Worker function image

phoenix-sample-ci-result

Task for creating a Result function image

phoenix-sample-ci-vote

Task for creating a Vote function image

For details about Vote, Result, and Worker, see Solution Architecture.

This section uses the phoenix-sample-ci task as an example. The following table shows the steps involved in this task.

Table 2 Build Actions

Build Actions

Description

Create Vote image and push it to SWR

Find Dockerfile in the working directory ./vote and Dockerfile directory ./Dockerfile, create a Vote image based on Dockerfile, and push the image to SWR.

Create Result image and push it to SWR

Find ./Dockerfile in the working directory ./result and Dockerfile directory ./Dockerfile, create and push the Result image based on Dockerfile, and push the image to SWR.

Install Worker dependency using Maven

Use Maven to install the dependency required by the Worker function.

Create Worker image and push it to SWR

Find Dockerfile.j2 in the working directory ./worker and Dockerfile directory Dockerfile.j2, create the Worker image based on Dockerfile, and push the image to SWR.

Generating Postgres and Redis Dockerfile

Run the shell command to generate Dockerfile for creating Postgres (database) and Redis (cache) images.

Create Postgres image and push it to SWR

Create a Postgres image based on Dockerfile generated in Create Postgres and Redis Dockerfile and push the image to SWR.

Create Redis image and push it to SWR

Create a Redis image based on Dockerfile generated in Create Postgres and Redis Dockerfile and push the image to SWR.

Replace image of Docker-Compose deployment file

To ensure that the correct image can be pulled when the image is deployed on ECS, run the shell command to perform the following operations:

Run the sed command to replace the parameters in the docker-compose-standalone.yml file with the dockerServer, dockerOrg, and BUILDNUMBER parameters of the build task in sequence.

Run the tar command to compress the docker-compose-standalone.yml file into the docker-stack.tar.gz file. Compress the files required for deployment so that the files can be uploaded and archived in subsequent steps.

Replacing the Image Version of the Kubernetes Deployment File

To ensure that the correct image can be pulled when the image is deployed on CCE, run the shell command to perform the following operations:

Run the sed command to replace the docker-server and docker-org parameters in all the files whose names end with deployment in the kompose directory with the dockerServer and dockerOrg parameters of the build task.

Run the sed command to replace image-version in the result-deployment.yaml, vote-deployment.yaml, and worker-deployment.yaml files with BUILDNUMBER.

Uploading the Kubernetes Deployment File to the Software Release Library

Upload all .yaml files to the software release library for archiving.

Uploading the docker-compose Deployment File to the Software Release Library

Upload the compressed docker-stack.tar.gz (build package directory) to the software release repo for archiving. Name the package docker-stack to manage versions of the software package.

During project deployment, failures often occur due to environment inconsistency. For example, after the JDK in the R&D debugging environment is upgraded, the JDK is not marked in the environment list. As a result, the production environment is not upgraded, causing failures. To avoid problems caused by environment inconsistency, Docker is used to package microservice applications and environments into images to ensure that each environment (development and commissioning environment, test environment, QA environment, and production environment) is consistent.

Configuring SWR

In this example, environment images are stored in SWR. Configure SWR first.

  1. Click Generate Login Command. The login command is displayed in a dialog box.

    where,
    • The character string following -u is the user name.
    • The character string following -p is the password.
    • The last character string is the address of the SWR server, which is the value of dockerServer for configuring and executing tasks later.

    The login instruction generated here is a temporary login instruction with a validity period of 24 hours. If a long-term valid login command is required, see Obtaining a Long-Term Valid Login Command.

  2. Click Create Organization. In the displayed dialog box, enter phoenix as the organization name and click OK. (The organization name must be globally unique. If a message is displayed indicating that the organization already exists, enter another name.)

    The organization name is the value of dockerOrg, which will be used for configuring and executing tasks later.

Configuring and Executing a Task

  1. Configure a task.

    1. Go to the Phoenix Mall project and choose CICD > Build. The built-in build task of the sample project is displayed on the page.
    2. Find the phoenix-sample-ci task in the list. Click and choose Edit from the drop-down list.
    3. Click the Parameters tab, and set parameters by referring to Table 3.
      Table 3 Setting Parameters

      Name

      Default Value

      codeBranch

      master

      dockerOrg

      Organization created in SWR. For this example, enter phoenix.

      version

      1.0.0

      dockerServer

      SWR server address obtained from SWR.

      Ensure that the values of dockerOrg and dockerServer are correct. Otherwise, the task fails.

  2. Click Save and Run. In the dialog box that is displayed, click OK and start the build task.

    When is displayed, the task is successfully executed. Record the character string starting with # (for example, ).

    If the build fails, rectify the fault based on the failed action information and error information in logs.

  3. Check the release file.

    1. Choose Artifact in the navigation pane and click the Release Repos tab.
    2. In the repository named after the project, you can find the docker-stack and phoenix-sample-ci folders.
      • In the docker-stack folder, you can find the folder named after the character string recorded in 2. In this folder, you can find the release file docker-stack.tar.gz.
      • In the phoenix-sample-ci/1.0.0 folder, you can find 10 archived .yaml files.
    3. Go to SWR. In the navigation pane, choose Organizations, and click the organization with the same name as the value of the build task parameter dockerOrg.

      Click the Images tab. You can find five images (redis, postgres, worker, result and vote) in the list.

      Figure 1 Viewing images
    4. Click the names of the five images in sequence to go to the image details page. View the image version on the Tags tab page.
      • The Redis image version is alpine.
      • The image version of postgres is 9.4.
      • The image versions of worker, result, and vote are the same as those recorded in 2.

Setting Code Submission to Trigger Automatic Compilation

After the following configuration, the application build task can be automatically triggered after the code is changed for continuous project integration.

  1. On the details page of the task phoenix-sample-ci, click Modify in the upper right corner of the page.
  2. Click the Schedule tab.
  3. Enable Run upon Code Commit. When is displayed, click Save.

    The default value of the codeBranch parameter on the parameter setting page is master. Therefore, the build is automatically triggered when the master code changes.

  4. Verify the configuration result: Modify the project code and submit it to master to check whether the build task is automatically executed.

Configuring Scheduled Execution

To prevent a code bug from entering the production environment and ensure that the application is always in a deployable state, the team recommends continuous verification of the application.

You can perform the following operations to execute the build task at a scheduled time:

  1. On the details page of the task phoenix-sample-ci, click Modify in the upper right corner of the page.
  2. Click the Schedule tab.
  3. Enable Scheduled Execution. After is displayed, and click Save.

    In this document, select All. The execution time is 12:00.

  4. Verify the configuration result: Check whether the build task is automatically executed at the configured time. We will not elaborate on the details in this section.

Parent topic: Procedure