️☁️End-to-End CodeArts Project Management Part 2: Leveraging APIs for Build and Deploy
Warning: The API endpoints and URIs may change in the future. Make sure they are not deprecated. You can refer to support links
🔦Introduction
Hi everyone, in this article, we will continue our project, which we started in Part 1 (link provided here). This time, we will utilize CodeArts and its Build and Deploy services without using the UI. This work will serve as a guideline, and you may find it valuable for your future business needs. If you are ready, let’s get to work.
💻Demo
Before we begin the demo, I’d like to provide some information on what we will be doing. We will continue with the demo by building the code we have using CodeArts Build. Afterward, we will deploy this build using CodeArts Deploy. Throughout these steps, we will make use of APIs, and we will use Postman for these tasks.
Prerequisites for this demo:
1️⃣ project_id and X-Auth-Token
We have these values noted from Part 1. If you don’t have these values and are unsure how to obtain them, I recommend referring to Part 1.
2️⃣ CodeArts Service Endpoints
When you create an API request, you need an endpoint and URI. I will give you the URIs step by step, but here I will give you the endpoints for the LA-Mexico City2 Region:
- Build: https://cloudbuild-ext.la-north-2.myhuaweicloud.com/
- Deploy: https://codearts-deploy.la-north-2.myhuaweicloud.com
3️⃣ An ECS with an EIP
When deploying an application, you require a server to perform deployment operations. In this case, we’ll need an ECS (Elastic Cloud Server) and its associated EIP (Elastic IP) within the CodeArts section. If you’re unfamiliar with how to create an ECS, I recommend referring to my previous article on the topic here.
CodeArts Build
CodeArts Build offers a user-friendly, cloud-based build platform that accommodates multiple programming languages. It facilitates continuous delivery by reducing delivery times and enhancing delivery efficiency. Using CodeArts Build, you can easily create, customize, and execute build tasks. It supports automated processes for code retrieval, build execution, and packaging, along with real-time status monitoring. Additionally, its distributed acceleration capabilities enable enterprises to enhance build efficiency and reduce costs, even when dealing with large-scale projects. Now let’s get started! (As mentioned in Part 1, CodeArts automatically generates check, build, and deploy tasks once you create a repository. While we manually created the check task in the previous article, in this installment, we will explore how to utilize the tasks that are automatically generated when using the build and deploy services.)
Firstly, we will list the build tasks for this project to identify the automatically created build task for our project. For this operation, we will use the following URI: (We won’t send a body in our request this time, but please remember to include the following headers in your requests from now on: X-Auth-Token;token-value and Content-Type;application/json.)
GET /v3/{project_id}/jobs
After the request is successfully completed, make sure to note down the ‘job_id’ (referred to as ‘id’ in this response) from the response body, as it will be essential for the next steps.
Once we have obtained the ‘job_id’ of the task you want to build, you can proceed with the build process. For this operation, our URI will be:
POST /v3/jobs/build
In the body of the request, you should include the ‘job_id’ that you obtained in the previous step. After the response of the request comes, you need to note down the ‘actual_build_number’ and ‘daily_build_number’, as we are going to use these build numbers in future operations, such as when we start the deployment.
Now, we need two pieces of information regarding the build process: its status and result. To check the task status, we will use this URI:
GET /v3/jobs/{job_id}/status
The response to the request will yield one of two options: ‘true’ or ‘false’. If it returns ‘false’, it indicates that the task has finished, and we can proceed to obtain the result.
To check the result of the task, we will use the ‘job_id’ and ‘build_number’ in this URI:
GET /v3/jobs/{job_id}/{build_number}/history-details
The response body will include information such as parameters, build steps, and their status. From this information, we can determine if the build task was successful or not.
After confirming that the build operation was successfully completed, we can now proceed to the deployment phase. Allow me to remind you of the requirement for an ECS server and a bonded EIP. If you haven’t set them up yet, now would be a good time to do so.
CodeArts Deploy
CodeArts Deploy offers visualized and automated deployment services, featuring a range of deployment actions that facilitate standard deployment processes, reduce deployment expenses, and enhance release efficiency. It supports multiple programming languages and technology stacks, including Tomcat, Spring Boot, Go, Node.js, Docker, and Kubernetes. Utilizing encapsulated and orchestrated capabilities in extensions, you can swiftly and effectively deploy your applications. Now, let’s commence the deployment process.
To begin the process, let’s list the deployment tasks in this project. This will provide us with information about the automatically created task for our repository. To do this, we will use the following URI:
GET /v2/{project_id}/tasks/list?page={page_value}&size={size_value}
This request will provide us with the deployment tasks in the project. In the response body, don’t forget to note down the `task_id` (referred to as `id` in this response) and `app_id` values. We will use them in the following steps.
Now we need to configure the deployment environment where we will deploy our application. To do this, we need to create a host cluster and then create a host within this cluster then we will create an environment in our deploy task. We will start with creating a host cluster and to create a host cluster, we will use this URI:
POST /v1/resources/host-groups
In the body of this request, we need to include parameters such as ‘name’, ‘project_id’, ‘os’ (operating system), and ‘is_proxy_mode’ (indicating whether the host cluster is in agent access mode: 1 for yes, 0 for no). After the request is successful, you should note down the ‘id’ (group_id) provided in the response body. This information will be needed for the next steps.
To create a host in this cluster, we will use the following URI:
POST /v1/resources/host-groups/{group_id}/hosts
In the body of this request, we will send parameters such as ‘host_name’, ‘ip’ (Elastic IP address of the ECS), ‘port’, ‘os’, ‘as_proxy’, ‘username’, ‘password’, and ‘trusted_type’(The value 0 indicates password authentication, and the value 1 indicates key authentication.). This will allow us to use our ECS within the host cluster and project. We will note down ‘id’ (host id) as we will need it in future operations.
After creating a host cluster and a host within it, we can now create an environment in our deploy task, which we will use when deploying the application. For this operation, we will use this URI:
POST /v1/applications/{application_id}/environments
In the body of this request, we will send the ‘project_id’, ‘name’, ‘deploy_type’ (The value can be 0 (host) or 1 (Kubernetes).), and ‘os’ parameters. After we receive the response, we will note the ‘id’ (environment_id) as we will use it later.
We are now entering the final parts of this demo, where we will import a host and complete the configuration process for our deployment environment where we will deploy our application. To import a host into our environment, we will use the following URI:
POST /v1/applications/{application_id}/environments/{environment_id}/hosts/import
In the body of this request, we are going to use ‘group_id’ and ‘host_ids’ (can be multiple) parameters.
Now we have configured the environment and everything is set for starting our deploy task. In order to start it we are going to use this URI:
POST POST /v2/tasks/{task_id}/start
In the body of this request, we will send the parameters ‘host_group’ (id of the environment we configured), ‘package_url’ (The artifact location of our build. For this demo it’s /{repository_name}-cloudbuild/{daily_build_number}/{package_name}.jar), ‘service_port’, and ‘package_name’. After sending this request, our deployment process will begin. After some time, you can access your application using the Elastic IP (EIP) of your ECS. In this demo, as you can see in the screenshot below, our Java Web Demo template code is successfully deployed.
👉Conclusion
In this article, we continued the work initiated in Part 1 and successfully built and deployed our code through CodeArts Build and Deploy services. During these steps, we exclusively utilized APIs (You can find the Postman Collection here) without relying on the CodeArts user interface. This approach not only enhanced our understanding of API usage but also provided a comprehensive insight into the capabilities of CodeArts services.
If you have questions or suggestions, you can always contact me through my LinkedIn page. I will include more articles in the future. See you then!
