Build a Dev Environment

In the application development process, the same business system developer may need to repeat the development environment setup many times. For example, the following situations:

  • Multiple new functions are iterated simultaneously in different branches, so different branch codes need to be deployed independently;
  • Multiple developers in the team develop, and each developer needs his own independent set of development environment;
  • The application development of the development environment is completed, and it is hoped to quickly deploy to the test environment or pre-release environment;
  • Gray release of production environment, hoping to quickly deploy specified components using specified source code versions;

In the above situation, if the application has only one component, it may not be complicated to create it from scratch. If the application includes 5 or more components, the creation process will consume a lot of time and is doing repetitive things. At this time, directly copying based on the deployed application can effectively solve the efficiency problem.


  1. Prepare a deployed application, which can include multiple components created using source code and images.
  2. Prepare at least two teams to verify cross-team application replication.
  3. The source code corresponding to the component can be prepared with multiple branches or mirrors can be prepared with multiple tags, and the build source version can be easily modified when verifying and copying.

Operating Procedures

  1. Enter the application view/overview topology page and click the quick copy button at the top right;
  2. The upper area of ​​the pop-up window displays the copied target application. The default is the current application. You can select a different team or application according to your needs, or you can directly create a new application in the specified team.
  3. The lower area of ​​the pop-up window displays all the component information of the current application and its construction source information. All components are selected for copy by default, and some components can be selected as needed. And you can change the build source version of the component as needed, such as the code branch or mirror tag.
  4. Click OK to start copying. After copying is complete, build and start all copied components by yourself, and the page jumps to the target application.

Understanding the Principle

The key embodiment of the application model

Kato defaults to abstract management of various types of software based on the application model, so copying is actually the copying of model attributes, which can ensure that the copied components are consistent with the source components. This once again illustrates that the process of deploying components in Kato is actually the process of assembling the application model. Once the deployment is completed, the definition of the business model is completed.

Handling of dependencies during component copy

There are currently two attributes associated with components, including component dependency and storage dependency. When copying a component, there are two situations, the component and the dependent component are copied together and only the relying party is copied. If both parties are replicated at the same time, then the dependency relationship between them will be maintained, and the new component will be established between the two parties, regardless of cross-team replication. If only the relying party is copied, there will be two processing modes. The copied target application is under the current team, and the copied new component still depends on the component that the source depends on. If the copied target application is not in the current team, the dependency is removed during copying.

Common Problems

The difference between application copy and installation after publishing to component library

Application copy is the copy of the attributes of the current application model. Versioning is not emphasized, and application template packaging is not performed. It is more flexible to use, suitable for development scenarios or testing and production delivery scenarios of the same development team. The process of publishing to the component library is the process of versioning and saving the application model. The construction source information of the application installed based on the component library template is the component library template, so continuous version upgrades can be carried out based on the component library template. This mode is suitable for the decoupling of application developers and users, and the application of multi-party and multi-environment delivery scenarios.

The difference between application replication and application backup migration

Application replication is the replication of application model attributes, so it will not carry any persistent data and component historical version data. Application backup migration is a process used to migrate all the data generated by the application in the production running state.

More Usage Scenarios

Rapid problem location and resolution of production environment components

There is a problem with a component in the production environment but it cannot be directly upgraded to solve it temporarily. We may need to modify part of the code to quickly verify whether it is effective. At this time, you can directly copy the problem component in the application and use the modified code version. Then modify the gateway policy, switch part of the traffic (for example, separate part of the traffic by the request path) to the new component to verify whether the problem is solved. This method does not affect the production components and can quickly solve the problem.