Development and deployment on the Choerodon platform are all about applications. What are the features of applications on the Choerodon platform? How is it managed? This article provides an in-depth look at the features and lifecycle management of applications in the Choerodon platform.
Characteristics of applications in microservices architecture
When it comes to applications on the Choerodon platform, microservices have to be mentioned. It is due to the emergence of microservices that the problems caused by the previous monolithic application architecture have been solved as follows:
(1) The coupling degree increases gradually with the passage of time.
(2) Poor scalability and redundancy
(3) Module division is not clear, unable to refine the demand for system resources
(4) The maintenance cost increases with the system becoming more and more bloated
The figure below illustrates the difference between a monolithic application architecture and a microservice architecture.
Thus, applications in a microservice architecture are broken down into smaller, completely independent components, making them more agile, scalable, and available. In other words, the basic idea of microservices architecture is to “build applications around business domain components that can be independently developed, managed, and accelerated.
Application lifecycle management in Choerodon platform
Because the Choerodon platform is a microservice architecture, each functional module within the system is decoupled into multiple applications, each of which can be independently developed and deployed. The life cycle of an application on Choerodon typically starts with the creation or import of the application; Then the application is developed according to the requirements in the development pipeline. After the submitted code runs CI, an application version will be generated, and the subsequent deployment and release operations are carried out around the application version. First, users can deploy the generated application version to the corresponding environment. In addition, users can publish the version of the application to the app market and share it with the whole platform or organization after it is tested correctly in the test environment.
This is the lifecycle of the Choerodon platform and how it works. Here’s how it works with DevOps.
Create or import an application
When creating or importing an application in the platform, the system will create a project in the corresponding GitLab group by default as the initial code base of the application, and then manage the application through the corresponding page function. The procedure for importing an application library from GitLab or Github is similar to that for creating an application. During the import process, you can still select the corresponding template library to facilitate subsequent development and deployment on the platform.
During the process of creating or importing an application, selecting an application template and configuring application permissions are indispensable steps and important features of an application. The following describes the two modules:
▌ Application Template
To help developers focus more on developing their applications, the Choerodon platform provides a comprehensive selection of preset application templates for each project team to choose from when creating an application. The application template is collated from the code base of the same type of application. After referencing the corresponding application template, you can quickly create the initial code base in GitLab.
At present, the pig toothfish platform presets many common application templates for development, such as microservice front-end, microservice back-end, Javalib(JAR library), Go language, SpringBoot, etc. In addition, there are Mocha and TestNg test application templates. These application templates are preset on Github. These templates contain at least Dockerfile files, CI files and Chart directory files.
Dockerfile is a script composed of a series of commands and parameters that are applied to the base image and eventually create a new image, mainly used to control the application containerized process. The second is the CI file, which is used in the template to set up all the phases that will go through when the code is submitted for automatic integration. The Chart directory file is used to package containers in the platform and put them on the K8S platform for management.
In addition to the preset templates provided by the platform, you can also customize application templates based on site requirements. User-defined templates will be placed in the application template library in GitLab for unified management by users.
▌ Application Permissions
It is well known that all project teams are made up of different roles. In the Project layer of the Choerodon platform, roles are simply divided into project owners and project members. As the name implies, the project owner corresponds to the role of project manager in the project, while project members are the other roles in the team. By default, the project owner has the development and deployment permissions of all applications under this item, and can configure application permissions for project members (currently, application permissions in the platform are limited to configuring application development permissions for project members).
In teams using microservices, where the management, development, and deployment of multiple cell applications are involved, and different applications may require different developers, it becomes even more necessary to configure permissions for each application. Choerodon provides flexible permission Settings when creating or importing applications at the project level within the platform, allowing the project owner to assign specific developers to the application.
Application development
Once the application is created, developers can work on the application as needed in the Choerodon platform’s development pipeline. The development pipeline is organized according to the daily operation of developers, mainly through the packaging of GitLab to achieve continuous integration and continuous delivery.
The development process in the platform begins with the creation of a branch based on the target application on which the rest of the development takes place. Once the development is complete and the code is committed, the CI is triggered and the phases defined in the CI file are executed in sequence. After the CI passes, an application version is generated based on the version generation rules (see The Application Version Management section). At this point, the merge request needs to be created in the development pipeline, and after the designated person reviews the code, the branch is merged into the target branch. At the end of the development process, users can use the tag function to create a tag for this version for better version management.
The following figure shows the main flow of the development pipeline module:
Application Version Management
The Choerodon platform features flexible version control and standard version management. Because of the semantic version naming rules, the version generated by THE Choerodon platform is generally in the format of C7N_COMMIT_time-C7n_branch. For example, if the branch name is feature-demo and the commit time is 20:14:54 on March 7, 2019, the C7N_VERSION value is 2019.3.7-201454-feature-demo. If the tag created through the tag function is 0.15.0, the resulting version number is 0.15.0. The marking function here is usually used when releasing a new version to the public, and the version format is usually: major version number. The second version number. The increment rule is as follows:
-
Major version number: When you make incompatible API changes,
-
Minor version number: When you make a backward-compatible feature addition,
-
Revision number: When you make a backward compatible problem fix.
In addition, Choerodon supports adding prior version numbers and version build information to “major version numbers”. Second version number. Revision number “to make the version number more flexible to understand, for example: 0.15.0-alpha.1. The specific rules can be understood in detail by semantic rules.
App publishing and the app marketplace
Many times, after an application is developed, another project or another organization may also need the application. In Choerodon platform, you only need to publish the corresponding version of the application to the whole organization or platform to realize application sharing within the organization or platform. Meanwhile, you can also control the specific version of the application. Optionally, the target version of the application can be released to the app market, and the pipelined-version of the application can be retained.
The application market is a collection of published applications accessible under the project, and the corresponding versions of the required applications can be deployed to the environment under the project. In addition, the application market provides application import and export functions (currently, you can import and export applications in ZIP format).
Application deployment
Application deployment is the main function in the deployment pipeline, and the process of application deployment is the process of application containerization.
Once the version of the application is built, it can be deployed to a Staging environment, UAT environment, or production environment for test acceptance or deployment. After the application is successfully deployed, an instance is generated, and we manage the application in the container by managing the instance and its related resources (detailed principles and steps will be described in a subsequent article on the deployment pipeline module).
The following is a schematic diagram of the pipeline module deployment process:
Monitor application dimension indicators
Peter Drucker: If you can’t measure it, you can’t improve it.
As Peter Drucker said, if you want to improve something, you have to have a clear indicator. DevOps metrics within Choerodon’s platform can be viewed on an application basis to see how each application is being developed and deployed.
(1) First of all, the code submission status of an application can be learned through the code submission map, so as to reflect the development status of the application in real time.
(2) In Choerodon, you can also see all builds of an application by application dimension, including the duration and number of builds.
(3) Finally, the deployment of an application in a certain environment or all environments can be known from the dimension of the application through the platform, including the deployment duration chart and deployment frequency chart.
Write in the last
Based on the microservices architecture, functional modules within the Choerodon platform are decoupled into multiple independent applications. It is important to manage these applications and their code base, and the Choerodon platform provides comprehensive features to help users better manage and share multiple applications. Application-centric development and deployment is an important part of the Choerodon platform practice DevOps, so application management as the foundation of practice DevOps should also be emphasized.
About the Choerodon toothfish
Choerodon is an open source, cloud-based application platform based on Kubernetes’ container orchestration and management capabilities, integrating DevOps tool chains, microservices and mobile application frameworks to help enterprises achieve agile application delivery and automated operations management. It also provides IoT, payment, data, intelligent insights, enterprise application marketplace and other business components to help enterprises focus on their business and accelerate digital transformation.
You can also learn about the latest developments of toothfish, product features and participate in community contributions through the following community channels:
- Liverpoolfc.tv: choerodon. IO
- BBS: forum. Choerodon. IO
- Github：github.com/choerodon
- Choerodon toothfish
- The Choerodon toothfish
Welcome to join the Choerodon Toothfish community to create an open ecological platform for enterprise digital services.