Help Center/ CodeArts/ Best Practices/ Using CodeArts to Manage an e-Mall Development Project/ Implementation Procedure/ Step 5: Building an Application
Updated on 2024-11-18 GMT+08:00
View PDF
Share

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.

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, we package microservice applications and environments into images in this example to ensure that the environments (development and commissioning, test, QA, and production) are consistent.

This section describes how Chris builds and archives images and software packages.

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 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

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 Action

Description

Build Vote Image and Push It to SWR

Create a Vote image using the vote/Dockerfile file in the code repository, and push the image to SWR.

Build Result Image and Push It to SWR

Create a Result image using the result/Dockerfile file in the code repository, and push the image to SWR.

Install Worker Dependency Using Maven

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

Build Worker Image and Push It to SWR

Create a Worker image using the worker/Dockerfile file in the code repository, and push the image to SWR.

Create Postgres and Redis Dockerfiles

Use shell commands to generate a Dockerfile for creating Postgres (database) and Redis (cache) images.

Build Postgres Image and Push It to SWR

Create a Postgres image using the Dockerfile generated in action Create Postgres and Redis Dockerfiles, and push the image to SWR.

Build Redis Image and Push It to SWR

Create a Redis image using the Dockerfile generated in action Create Postgres and Redis Dockerfiles, and push the image to SWR.

Replace Image Version of Docker-Compose Deployment File

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

  1. Run sed commands to replace the parameters in the docker-compose-standalone.yml file with the dockerServer, dockerOrg, and BUILDNUMBER parameters of the build task in sequence.
  2. 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.

Replace Image Version of Kubernetes Deployment File

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

  1. Run the sed commands to replace the docker-server and docker-org parameters in all the files whose names end with deployment in the kompose directory of the code repository with the dockerServer and dockerOrg parameters of the build task.
  2. Run the sed commands to replace image-version in the result-deployment.yaml, vote-deployment.yaml, and worker-deployment.yaml files of the code repository with BUILDNUMBER.

Upload Kubernetes Deployment File to Release Repo

Upload all .yaml files modified in action Replace Image Version of Kubernetes Deployment File to the release repo for archiving.

Upload Docker-Compose Deployment File to Release Repo

Upload the docker-stack.tar.gz package generated in action Replace Image Version of Docker-Compose Deployment File to the release repo for archiving.

Configuring SWR

This example uses SWR to store environment images. Before executing tasks, obtain the SWR login command and create an organization.

  1. In CodeArts, click Console on the navigation bar. Click in the upper left corner, then search for and access SWR.

    Check the region list in the upper left corner of the page and ensure that the region is the same as the region where the build task is compiled. If the regions are different, select the same region.

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

    In this command,
    • The character string following -u is the username.
    • 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.
    Figure 1 Generating a login command

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

  3. Click Create Organization. In the displayed dialog box, enter phoenix as the organization name and click OK. (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 tasks of the sample project are displayed on the page.
    2. Find the phoenix-sample-ci task in the list. Click and choose Edit.
    3. Click the Parameters tab and set parameters by referring to Table 3.
      Table 3 Setting parameters

      Name

      Default Value

      codeBranch

      master

      dockerOrg

      phoenix (name of the organization created in SWR)

      version

      1.0.0

      dockerServer

      SWR server address obtained from SWR.

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

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

    If 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 and the error information in logs.

  3. Check the release file.

    1. Choose Artifact from the navigation pane and click the Release Repos tab.
    2. In the repository named after the project, find the docker-stack and phoenix-sample-ci folders.
      • In the docker-stack folder, find the folder named after the character string recorded in 2. Then find the release file docker-stack.tar.gz in this folder.
      • In the phoenix-sample-ci/1.0.0 folder, find the 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. Then find the five images (redis, postgres, worker, result, and vote) in the list.

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

Configuring Auto Compilation upon Code Commits

After the following configuration, code changes will automatically trigger the application build task, achieving continuous integration.

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

    The default value of codeBranch on the Parameters tab is master. Therefore, the build is automatically run when the code in master code is changed.

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

Configuring Scheduled Execution

To prevent code bugs from entering the production environment and ensure that the application is always deployable, 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 task phoenix-sample-ci, click Edit.
  2. Click the Schedule tab.
  3. Enable Scheduled Execution ( means enabled), select days and time, disable Upon Code Change, and click Save.

    For this example, select All, and set the execution time to 12:00. (This example uses the default time zone. You can change it to the one you use.)

  4. Check whether the build task is automatically executed at the configured time.
Parent topic: Implementation Procedure