Software Technology for Software development and deployment across multiple environments

Invented by Liujin Yu, Gregory Charles McNutt, Alibaba com Ltd

The Alibaba com Ltd invention works as follows

Background for Software development and deployment across multiple environments

In traditional development and deployment techniques, configuration information, including security information, was deployed and persistently saved at systems where one or multiple instances of one type of environment were to be run. Users from different environments can edit the source code for the configuration information shared between the environments. Problems arise, however, when a user of a particular type of environment changes the source code to the detriment of a different type of environment.

Also, it is not easy to write a generic application which works in all environments. Some traditional methods are prone to error. You can edit the?/etc/hosts/? To resolve hostname problems, you can edit?/etc/hosts? This is usually reserved for more advanced developers. A different approach is to use many if/else statements in the source code of the configuration information to differentiate how the data of the environment is handled. This creates many code paths which will only run in one environment. It makes it difficult to test/debug issues in one environment (e.g. development) in another environment (e.g. production).

The invention may be implemented in many ways. It can be used as an apparatus, a process, a system, a composition, a product of computer programming, and/or a CPU, such as one that executes instructions stored on or provided by a memory connected to the processor. These implementations and any other form of the invention can be called techniques in this specification. The invention allows for the possibility of altering the order of steps in disclosed processes. A component, such as a processor and a memory, described as being capable of performing a task can be implemented either as a general component that is temporarily set up to perform the task at a particular time or as a specific component that was manufactured to do the task. The term “processor” is used herein. The term “processor” refers to any one or more devices, circuits and/or processing cores that are designed to process data such as computer program instruction.

Below is a detailed description of some embodiments of the invention, along with accompanying figures that illustrate its principles. Although the invention is described with these embodiments in mind, it is not limited to them. The claims limit the scope of the invention, and the invention includes many alternatives, modifications, and equivalents. The following description provides a detailed understanding of the invention. These details are given for example purposes only. The invention can be used according to the claims without any or all of these details. To be clear, the technical material related to the invention that is well-known has not been described in detail. This is done in order not to obscure the invention.

This invention describes a technique for developing, deploying and operating an app in multiple environments. In different embodiments, runtime configuration information is defined for a plurality environment types. A set of information is defined for a development or production environment, and another set is defined for a QA test environment. Sets of configuration information can include topology and security configuration. In some embodiments the sets of configuration information specific to an environment are stored separately from any other configuration data (e.g. web application data which may or may be not specific to a particular environment) and protected by a identity management system. In some embodiments the sets of configuration data are stored remotely or in a central management system for configuration information. The sets of environment-specific configuration information can be stored centrally and easily located to update or for other purposes.

In various embodiments, an identity management system protecting the sets environment-specific configuration information might only allow a small set of security roles access to and modification of the configuration information. This limited set of roles, for example, a security manager, can modify configuration information in the central configuration system. In some embodiments, an identity management system protecting the environment-specific configuration information allows another set of roles to access those sets during runtime but not modify them. This other set of roles, for example, is linked to roles responsible for running instances of different environments, such a production application managers, and can submit the appropriate credentials from the central configuration management system to access the set configuration information that they require. A security role that is responsible for managing the production environment, may have credentials allowing them to access a set of configuration information specific to the production environment but not the QA environment. Security roles may be different in various embodiments. In some cases, security roles may have access to and modify sets of configuration information specific to an environment. Other times, security roles may only have access. In order to avoid leaks of security key, different security roles can be assigned among a group of users. A few users may be assigned a role as a security manager, who may modify sets of environment-specific configuration information. The other users may be assigned an environment-specific manager role, which only allows them to read the configuration information associated with the environment.

By keeping the sets environment-specific configuration information separate from other configuration data, and managed by roles that are not primarily responsible for managing specific environments, these sets can be updated centrally by limited users. The updated sets environment-specific configuration information could be managed so they only go to specific environments at runtime. This system could prevent the unintended leakage of security keys between environments, and make it easier to manage sets of environment-specific configuration information across multiple environments.

FIG. The diagram 2 shows an example of how to instantiate an application in a production environment. The example in FIG. can be used to instantiate an application within the production environment 104. 2. In this example, an user with the production application manager role (102 in this case) wishes to instantiate a production application 104. He submits his credentials (e.g. over a network), to an identity system that protects a central configuration information management (not shown). The identity management system will confirm that the credentials provided by the user have been accepted. Once this is confirmed, the user in production application manager roles 102 has read-only access granted to the set configuration information specific for production environment 104, stored at the central information management system. This is the set production environment configuration information. Set of production information configuration 202 can be modified or defined by an individual associated with the security manager role, which is not typically a member of the production application manager role. Set of production environment information 202, as shown in the example includes both topology and security configurations for the production environment. The application is instantiated based on the set of production information configuration 202 and other configuration data, which are not environment-specific. Other configuration data can come from WAR files that were used to implement the app or the same services that provided some security configuration. Other configuration data can also include constants for each application instance or for a specific application.

The application in the example is represented by the content of the box shown for production environment 104. The topology configuration of the set of production-environment configuration information 202 in the example may indicate that the application can be accessed externally at URL www.app.com. It should also utilize load balancers 206 to distribute workload between two computers (Computer 1 & Computer 2), use service SVC1204, which is the cloud service 110 supported service, at URLs svc1.app.com and access database service SVC2206 at URLs svc2.app.com. (SVC SVC 1 represents two sub-services, with different endpoint names. Security keys 210 are used to access cloud service for service SVC1 in the example. Security keys 212 are used to access database services SVC2 206. Security keys 210, 212 can each be a credential or password and/or another form of authentication. “In some embodiments, set of production-environment configuration information 202 may be temporarily stored with production environment 104 (e.g. in memory) during the runtime for this application.

FIG. A flow diagram 3 shows an embodiment of a method for developing, deploying and operating an app in multiple environments. In some embodiments process 300 can be implemented on system 100.

At 302, runtime-specific configuration information for a plurality environments is defined, the runtime-specific configuration information including topology configuration and a security configuration. The runtime-specific configuration information are stored separately from the other configuration information, and protected by an Identity Management System. In some embodiments a different set of configuration data is defined for every type of environment. Each set of configuration data may, for example, include the topology configuration as well as security configurations for each environment type. Types of environments can include production, development and QA. The sets of configuration data specific to an environment are stored separately. The sets of environmental specific configuration data are protected by an Identity Management System that allows one set of user associated with a type of security roles (e.g. an environment specific role) to have privileges only to read one or several of the configuration information sets and another group of users with a different type of role (e.g.,’security manager role’) to be able to read as well as modify one or multiple sets of configuration data. In some embodiments a user can be a human operator, or a machine (e.g. a computer program). In some embodiments the privilege level for a security role can be determined by the credentials that are associated with the role.

At 302, an application in one environment is executed. The application’s execution is controlled by the first role. In some embodiments an application may be executed during runtime in one of the environments that were defined by a set environment-specific configuration information. In some embodiments the application is run as a result a first role user entering computer commands or making selections on a device that executes the application. In some embodiments this user is assigned a security role associated with the environment where the application is running.

At 306, an identity management system receives a credential associated the first role to obtain a part of the runtime specific configuration associated with the environment associated with executing the application. In some embodiments credentials (e.g. a password, or any other authentication form) associated with a user’s role are presented to the Identity Management System that protects sets of information about the environment. If the identity management system authenticates a user, the identity management will allow the user to retrieve the configuration information for the environment where the application is running. In some embodiments a copy may be kept locally by the user or the system on which the application runs. The application may use environment specific topology configuration and security configuration of the retrieved set of environment specific configuration to receive external communication/traffic and access (via authentication with security keys) to internal components in the deployment.

FIG. The flow diagram of FIG. 4 shows an example of how to develop, deploy, and operate an application within one of several environments. In some embodiments process 400 can be implemented on system 100.

At 402, a application is instantiated in an environment. In some embodiments an application can be instantiated by a user who has a security role that is associated with the type of environment in question (e.g. production, development, or QA). Instantiating an application can include creating the application with any appropriate build framework. “For example, you can create a Maven-based web application and then wire the configuration at the application level using Spring Framework.