DEPLOYING A SOFTWARE RELEASE TO A DATA CENTER CONFIGURED IN A CLOUD PLATFORM

Abstract

A computing system, e.g., a multi-tenant system, deploys software artifacts in a data center created in a cloud platform using a cloud platform infrastructure language that is cloud platform independent. The system receives an artifact version map that identifies versions of the software artifacts for data center entities in the data center, and a cloud platform-independent master pipeline that includes instructions for performing operations related to services on the data center, such as deploying the software artifacts, provisioning computing resources, etc. The system compiles the cloud platform-independent master pipeline in conjunction with the artifact version map to generate a cloud platform-specific detailed pipeline that deploys appropriate versions of the deployment artifacts to the data center entities according to the artifact version map. The system submits the cloud platform-specific detailed pipeline to a target cloud platform for execution.

Description

[Technical field]

[0001] The present disclosure relates generally to managing software releases in a cloud computing platform, and more particularly to deploying software releases on data centers configured in a cloud computing platform. [Background technology]

[0002] Organizations are increasingly turning to cloud platforms (or cloud computing platforms), such as AWS (AMAZON WEB SERVICES), GOOGLE CLOUD PLATFORM, MICROSOFT AZURE, etc., for their infrastructure needs. Cloud platforms provide servers, storage, databases, networking, software, etc. to organizations over the Internet. Traditionally, organizations maintain data centers that house the hardware and software used by the organization. However, maintaining a data center can result in significant overhead in terms of maintenance, personnel, etc. As a result, organizations are migrating their data centers to cloud platforms that offer scalability and elasticity of computing resources.

[0003] An organization maintains a cloud infrastructure on a cloud platform using a continuous delivery platform that can manage and deploy applications on the cloud platform. Such a continuous delivery platform allows an organization to simplify the software deployment process and manage applications, firewalls, clusters, servers, load balancers, and other computing infrastructure on the cloud platform. However, using a continuous delivery platform to deploy software releases for services offered on the cloud platform can be complicated. For example, different versions of software may need to be deployed to different services running on different cloud computing resources. Furthermore, each cloud platform uses different tools to manage resources.

[0004] A large system, such as a multi-tenant system, may manage services for multiple organizations that represent tenants of the multi-tenant system and may interact with multiple cloud platforms. The multi-tenant system may have to maintain thousands of data centers on the cloud platform. Each data center may have different requirements for software releases. Furthermore, the software, languages, and features supported by each cloud platform may differ. For example, different cloud platforms may support different mechanisms for implementing network policies or access control. As a result, the multi-tenant system must maintain different implementations of mechanisms for releasing and deploying services on a data center depending on the number of cloud platforms supported for the data center. As a result, maintenance costs are high for the multi-tenant system to support software releases on data centers across multiple cloud platforms. [Brief description of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram of a system environment illustrating a multi-tenant system that configures a data center on a cloud platform, according to one embodiment.

[0006] [Figure 2A] 2 is a block diagram illustrating a system architecture of a deployment module 210 according to one embodiment.

[0007] [Figure 2B] 1 illustrates an overall process for deploying software artifacts in a data center, according to one embodiment.

[0008] [Diagram 3] FIG. 2 is a block diagram illustrating the architecture of a software release management module, according to one embodiment.

[0009] [Figure 4] 1 illustrates an example of a data center declarative specification, according to one embodiment.

[0010] [Diagram 5] 1 illustrates an exemplary data center created on a cloud platform based on a declarative specification, according to one embodiment.

[0011] [Figure 6] FIG. 2 is a block diagram illustrating the creation of a data center on a cloud platform based on a declarative specification, according to one embodiment.

[0012] [Figure 7] 1 illustrates an overall process for generating a pipeline for deploying software artifacts to a data center configured on a cloud platform, according to one embodiment.

[0013] [Figure 8]1 illustrates an exemplary master pipeline, according to one embodiment.

[0014] [Figure 9] 1 illustrates the overall process performed by stages for an environment of a master pipeline on a cloud platform, according to one embodiment.

[0015] [Figure 10] 1 illustrates an exemplary master pipeline, according to one embodiment.

[0016] [Figure 11] 1 illustrates an exemplary master pipeline for a data center, according to one embodiment.

[0017] [Figure 12] 1 illustrates how the execution of a master pipeline is modified based on an artifact version map, according to one embodiment.

[0018] [Figure 13] 1 illustrates an overall process for deploying software artifacts to a data center configured on a cloud platform, according to one embodiment.

[0019] [Figure 14] 2 is a block diagram illustrating a functional diagram of a typical computer system for use in the environment of FIG. 1, according to one embodiment.

[0020] The drawings depict various embodiments for purposes of illustration only. Those skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the embodiments described herein.

[0021] The figures use like reference numbers to identify like elements. Letters following a reference number, such as "115a," indicate that the text is specifically referring to the element having that particular reference number. A reference number in the text without a following letter, such as "115," refers to any or all of the elements in the figure having that reference number. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] A cloud platform provides computing resources, such as storage, computing resources, and applications, to computing systems on an on-demand basis over a public network, such as the Internet. Cloud platforms allow companies to minimize the initial costs of setting up computing infrastructure, and companies can quickly get applications up and running with less maintenance overhead. Cloud platforms also allow companies to adjust computing resources to rapidly fluctuating and unpredictable demand. Companies can create data centers using cloud platforms for use by the company's users. However, implementing a data center on each cloud platform requires expertise in the technology of the cloud platform.

[0023] An embodiment includes a computing system that creates a datacenter in a cloud platform using a cloud platform agnostic cloud platform infrastructure language. The system receives a declarative specification for the cloud platform agnostic datacenter. The declarative specification describes the structure of the datacenter and may not provide instructions that specify how to create the datacenter. The cloud platform agnostic declarative specification is configured to create the datacenter in any of a plurality of cloud platforms and is specified using the cloud platform infrastructure language. The system receives information identifying a target cloud platform for creating the datacenter and compiles the cloud platform agnostic declarative specification to generate a cloud platform specific datacenter representation. The system transmits the cloud platform specific datacenter representation and a set of instructions for execution on the target cloud platform. The target cloud platform executes the instructions to configure the datacenter using the platform specific datacenter representation. The system provides a user with access to computing resources of the datacenter configured by the cloud platform.

[0024] In one embodiment, the system performs operations related to a software release at a data center configured on a cloud platform, such as deploying the software release, provisioning resources, performing a rollback of the software release, etc. The system accesses a data center configured on a target cloud platform. The data center is generated based on a cloud platform independent declarative specification that includes a hierarchy of data center entities. Each data center entity includes one or more of: (1) a service, or (2) one or more other data center entities. The system generates a cloud platform independent master pipeline that includes: (1) a sequence of stages for deploying software artifacts, such as a development stage, a test stage, a production stage, and (2) criteria for promoting the software artifacts from one stage to a subsequent stage in the sequence of stages. The system compiles the cloud platform independent master pipeline to generate a cloud platform dependent detailed pipeline for the target cloud platform with instructions for performing operations related to the service according to the layout of the data center defined in the declarative specification. The system executes a cloud platform dependent detailed pipeline on a target cloud platform to deploy, for example, a software release to data center entities in a data center.

[0025] In one embodiment, the system accesses a datacenter configured on a target cloud platform. The system receives a cloud platform independent artifact version map that associates datacenter entities of the datacenter with versions of software artifacts targeted to be deployed to the datacenter entities. Each software artifact includes executable instructions associated with a service configured to run on one or more cloud platforms. The system generates a cloud platform specific master pipeline for the target cloud platform based on the cloud platform independent artifact version map. The cloud platform specific master pipeline includes instructions for performing operations such as building and deploying appropriate versions of deployment artifacts of the service on the datacenter entities according to the cloud platform independent version map. The system sends the cloud platform specific deployment pipeline to the target cloud platform for execution. The artifact version map and the master pipeline can be used to perform various actions related to the service, including deploying the service, destroying the service, provisioning resources for the service, destroying resources for the service, etc.

[0026] A cloud platform is also referred to herein as a substrate. A declarative specification of a data center is substrate independent or substrate agnostic. If operations related to a data center, such as deploying a software release, provisioning resources, etc., are performed with traditional techniques, the user must provide instructions specific to the cloud platform. Thus, the user requires expertise of the cloud platform used. Furthermore, the instructions are cloud platform specific and not portable across multiple platforms. For example, instructions for deploying software on the AWS cloud platform are different from instructions on the GCP cloud platform. The developer needs to understand the details of how each function is implemented on that particular cloud platform. The disclosed system provides a cloud platform infrastructure language that enables a user to perform operations on a data center using instructions that are cloud platform independent and executable on any cloud platform selected from multiple cloud platforms. A compiler for the cloud platform infrastructure language generates cloud platform specific detailed instructions for the target cloud platform.

[0027] The cloud platform infrastructure language may be referred to as a Domain Specific Language (DSL). The system may represent a multi-tenant system, but is not limited to being a multi-tenant system, and may be any online system or any computing system with network access to a cloud platform. System Environment

[0028] 1 is a block diagram of a system environment illustrating a multi-tenant system constituting a data center on a cloud platform, according to one embodiment. System environment 100 includes multi-tenant system 110, one or more cloud platforms 120, and one or more client devices 105. In other embodiments, system environment 100 may include more or fewer components.

[0029] The multi-tenant system 110 stores information for one or more tenants 115. Each tenant may be associated with a business that represents a customer of the multi-tenant system 110. Each tenant may have multiple users that interact with the multi-tenant system via client devices 105.

[0030] A cloud platform may also be referred to as a cloud computing platform or a public cloud environment. A tenant may use a cloud platform infrastructure language to provide a declarative specification of a data center created on a target cloud platform 120 and use the data center to perform operations such as, for example, provisioning resources, running software releases, etc. A tenant 115 may create one or more data centers on the cloud platform 120. A data center represents a set of computing resources such as servers, applications, storage, memory, etc. that may be used by a user, e.g., a user associated with the tenant. Each tenant may present different functionality to the users of that tenant. Thus, each tenant may run different services on the data center configured for that tenant. A multi-tenant system may implement different mechanisms for software release and deployment for each tenant. A tenant may further obtain or develop a version of software that includes instructions for various services running on the data center. An embodiment allows a tenant to deploy a specific version of a software release for different services running on different computing resources of a data center.

[0031] The computing resources of a data center are secure and cannot be accessed by users who are not authorized to access them. For example, a data center 125a created for users of tenant 115a cannot be accessed by users of tenant 115b unless access is explicitly permitted. Similarly, a data center 125b created for users of tenant 115b cannot be accessed by users of tenant 115a unless access is explicitly permitted. Furthermore, services provided by a data center may be accessed by a computing system outside the data center only if the computing system is granted access according to the declarative specification of the data center.

[0032] In a multi-tenant system 110, data for multiple tenants may be stored in the same physical database. However, the data of one tenant may be configured to be kept logically separate from the data of other tenants, such that one tenant does not have access to another tenant's data unless such data is explicitly shared. It is transparent to the tenant that a tenant's data may be stored in tables shared with data of other customers. A database table may store rows for multiple tenants. Thus, in a multi-tenant system, various elements of the system's hardware and software may be shared by one or more tenants. For example, the multi-tenant system 110 may run application servers that process requests for multiple tenants simultaneously. However, the multi-tenant system may enforce tenant-level data isolation to ensure that one tenant's jobs do not access other tenants' data.

[0033] Examples of cloud platforms include Amazon Web Services (AWS), GOOGLE Cloud Platform, or MICROSOFT AZURE. The cloud platform 120 presents computing infrastructure services that may be used on-demand by tenants 115 or by any computing system outside the cloud platform 120. Examples of computing infrastructure services provided by the cloud platform include servers, storage, databases, networking, security, load balancing, software, analytics, intelligence, and other infrastructure service capabilities. These infrastructure services may be used by tenants 115 to build, deploy, and manage applications in a scalable and secure manner.

[0034] The multi-tenant system 110 may include a tenant data store that stores data for various tenants of the multi-tenant store. The tenant data store may store data for different tenants in separate physical structures, for example, separate database tables or separate databases. Alternatively, the tenant data store may store data for multiple tenants in a shared structure. For example, user accounts for all tenants may share the same database table. However, the multi-tenant system stores additional information to logically separate the data for different tenants.

[0035] Each component shown in Figure 1 represents one or more computing devices. The computing devices may be, for example, conventional computer systems running a Microsoft® Windows® compatible operating system (OS), Apple® OS X, and / or a Linux® distribution. The computing devices may be client devices having computing capabilities, such as personal digital assistants (PDAs), mobile phones, video game systems, etc. Each computing device stores software modules that store instructions.

[0036] Interaction between the various components of system environment 100 is typically performed over a network, not shown in Figure 1. In one embodiment, the network uses standard communication technologies and / or protocols. In another embodiment, the entities may use custom and / or proprietary data communication technologies instead of or in addition to those described above.

[0037] Although the techniques disclosed herein are described in the context of a multi-tenant system, these techniques may be implemented using other systems, which may not be multi-tenant systems. For example, an online system used by a single organization or enterprise may use the techniques disclosed herein to create one or more data centers on one or more cloud platforms 120. System Architecture

[0038] The multi-tenant system 110 includes a deployment module for deploying software artifacts to a cloud platform. The deployment module can perform various operations associated with a software release, such as provisioning resources on the cloud platform, deploying the software release, performing rollback of software artifacts installed on data center entities, etc. Figure 2 is a block diagram illustrating a system architecture of a deployment module 210 according to one embodiment. The deployment module 210 includes a data center creation module 220 and a software release management module 230. Other embodiments may have different and / or other components than those described herein, and functionality may be distributed among the components in a different manner.

[0039] The data center creation module 220 includes instructions for creating a data center in the cloud platform. The software release management module 230 includes instructions for deploying software releases for various services or applications that run on the data center created by the data center creation module 220.

[0040] The data center generation module 220 receives a cloud platform independent declarative specification of a data center from a user, e.g., a tenant user. The cloud platform independent declarative specification of a data center defines various entities of the data center. In one embodiment, the cloud platform independent declarative specification of a data center includes a hierarchical organization of data center entities, where each data center entity may include one or more services, one or more other data center entities, or a combination of both. FIG. 4 describes the various types of data center entities in more detail. The data center generation module 220 receives the platform independent declarative specification and a target cloud platform as input and generates a cloud platform specific metadata representation for the target cloud platform. The data center generation module 240 deploys the generated cloud platform specific metadata representation to the target cloud platform according to the declarative specification to create a data center in the target cloud platform.

[0041] Software release management module 230 receives as inputs (1) artifact version map 225 and (2) master pipeline 235. Artifact version map 225 identifies specific versions of software releases or deployment artifacts targeted for deployment to specific datacenter entities. Artifact version map 225 maps datacenter entities to software release versions targeted for deployment to the datacenter entities. Master pipeline 235 contains instructions for operations related to software releases on the datacenter, such as, for example, deploying a service, destroying a service, provisioning resources for a service, destroying resources for a service, etc.

[0042] The master pipeline 235 may include instructions for performing operations related to a software release for different environments, such as a development environment, a test environment, a canary environment, and a production environment, and instructions for determining when a software release is promoted from one environment to another. For example, if a deployment of a software release in a development environment executes more test cases than a threshold, the software release is promoted to a test environment for further testing, e.g., system-level and integration testing. If the software release in the test environment exceeds a threshold of test coverage, the software release is promoted to a canary environment where the software release is provided to a small subset of users on a trial basis. If the software release in the canary environment runs without errors for a threshold time, the software release is promoted to a production environment where the software release is provided to all users.

[0043] The software release management module 230 compiles the input artifact version map 225 and the master pipeline 235 to generate a cloud platform specific detailed pipeline 255 that is sent to the target cloud platform. The cloud platform specific detailed pipeline 255 includes instructions for deploying the appropriate version of the software release or deployment artifact to the data center entity as specified in the artifact version map 225. The software release management module 230 may receive a modification to one of the inputs. For example, a user may modify the input artifact version map 225 and provide the same master pipeline 235. Thus, the same master pipeline is used, but a different software release is deployed to the data center entity. The software release management module 230 recompiles the inputs to generate a new cloud platform specific detailed pipeline 255 that deploys the version of the software release according to the new artifact version map 225.

[0044] The artifact version map may also be referred to as a deployment manifest, a version manifest, a software release map, or a software artifact version map. The master pipeline may also be referred to as a master deployment pipeline or a master orchestration pipeline.

[0045] FIG. 2B illustrates an overall process for deploying software artifacts in a data center according to one embodiment. FIG. 2B shows a layout of a data center 265 including various data center entities. As shown in FIG. 2B, an artifact version map 225 identifies different versions of software targeted for release to different data center entities 275 of the data center 265. A master pipeline represents the flow of deployment artifacts in various environments of the data center. The software release management module 230 combines the information in the master pipeline 235 with the artifact version map 225 to determine a cloud platform specific detailed pipeline 255 that maps appropriate versions of software artifacts on the data center entities according to the artifact version map 225.

[0046] 3 is a block diagram illustrating the architecture of a software release management module 230 according to one embodiment. The software release management module 230 includes an analysis module 310, a pipeline generator module 320, an artifact version map store 330, a pipeline store 340, and a pipeline execution engine 360. Other embodiments may include more, fewer, or different modules than those illustrated herein in FIG.

[0047] The parsing module 310 parses various types of user inputs, including declarative specifications of data centers, artifact version maps 225, and master pipelines 235. The parsing module 310 generates data structures and metadata representations of the processed inputs and provides the generated data structures and metadata representations to other modules of the software release management module 230 for further processing.

[0048] The metadata store 340 stores various transformed metadata representations of the data center generated by the software release management module 230. The transformed metadata representations may be used to perform rollbacks to previous versions in the event of issues with the current version of the data center. The transformed metadata representations may be used for validation, auditing, governance, etc. at various stages of the transformation process.

[0049] The pipeline generator module 320 processes the master pipeline together with the artifact version map received as input to generate a detailed pipeline for the target cloud platform. The pipeline includes stages containing instructions for provisioning a service or deploying an application to deploy versions of a software release for various services on the cloud platform according to the artifact version map. The artifact version map store 330 stores the artifact version map received from the user, and the pipeline store 340 stores the master pipeline as well as the pipelines generated by the pipeline generator module 320.

[0050] The pipeline execution engine 360 ​​executes the detailed pipeline generated by the pipeline generation module 320. In one embodiment, the pipeline execution engine 360 ​​is a SPINNAKER-like system that executes pipelines for software release / deployment. The pipeline execution engine 360 ​​analyzes the pipeline and executes each stage of the pipeline on a target cloud computing platform. Cloud Platform-Based Data Center Creation

[0051] 4 illustrates an example of a declarative specification of a data center, according to one embodiment. The declarative specification 410 includes multiple data center entities. A data center entity is an instance of a data center entity type, and there may be multiple instances of each data center entity type. Examples of data center entities include a data center, a service group, a service, a team, an environment, and a schema.

[0052] The declarative specification 410 includes definitions of various types of datacenter entities, including service groups, services, teams, environments, and schemas. The declarative specification includes one or more instances of a datacenter. The following describes various types of datacenter entities and examples thereof. The examples are illustrative and show some of the attributes of the datacenter entities. Other embodiments may include different attributes, and attributes with the same functionality may be given different names than those shown herein. In one embodiment, the declarative specification is specified using hierarchical objects, e.g., Javascript object notation (JSON), that conform to a predefined schema.

[0053] A service group 520 represents a set of capabilities, features, and services offered by one or more computing systems that can be built and delivered independently, according to one embodiment. A service group may also be referred to as a logical service group, a functional unit, or a bounded context. A service group 520 may be viewed as a set of services for a set of comprehensive technical use case functionality provided by one or more computing systems. A service group 520 enforces security boundaries. A service group 520 defines the scope of modifications. Thus, any changes to entities such as capabilities, features, services, etc., provided by one or more computing systems in a service group 520 may be propagated as needed or preferred to entities within the service group 520, but not to entities that exist outside the bounded definition of the service group 420. A data center may include multiple service groups 520. A service group definition specifies attributes such as a name, description, identifier, schema version, and a set of service instances. An example of a service group is a blockchain service group that includes a set of services used to provide blockchain functionality. Similarly, a security service group provides security features. A user interface service group provides functionality for a particular user interface feature. The Shared Documents service group provides the ability to share documents across users. There may be multiple other service groups as well.

[0054] Service groups support reusability of specifications so that a tenant or user interested in developing a data center can have a library of service groups that can be easily used. The boundaries of services in a service group are based on security and network concerns, among others. A service group is associated with a protocol for performing interactions with the service group. In one embodiment, a service group provides a collection of APIs (Application Programming Interfaces) and services that implement those APIs. Furthermore, service groups are substrate independent. A service group provides a blast radius for services within the service group so that any failure of a service within the service group is limited to the impact on the services within the service group and the impact outside the service group is minimized.

[0055] The following is an example of a service group specification: The service group defines various attributes that represent metadata of the service group and includes the set of services within the service group. There may be other types of metadata defined for the service group that are not shown here.

number

[0056] As shown in the above example, a service group may define a set of clusters. A cluster represents a set of computing nodes, e.g., a set of servers, a set of virtual machines, or a set of containers (such as KUBERNETES containers). A physical server may run multiple containers, and each container has its own share of filesystems, CPUs, memory, process space, etc.

[0057] A service group specifies a set of services. A service group may specify clusters for the services such that a data center deployed in a cloud platform runs a cluster of computing nodes and if included in the declarative specification, maps the services to the clusters based on the specified mapping. For example, in the example service group above, service instance serviceinstance0002 is specified to run on cluster instance cluster1.

[0058] A service group may define security groups, each of which defines a set of services that are allowed to interact with each other. Services outside the security group are required to go through additional authentication to communicate with services in the security group. Alternatively, services in the security group use one protocol to interact with each other, and services outside the security group use a different protocol that requires extended authentication to interact with services in the security group. Thus, a security group defines a policy that determines how services can interact with each other. A security policy may define one or more environments for which security policies are applicable. For example, a security policy policy1 may be applied to a particular environment env1 (e.g., production environment), and another security policy policy2 may be applied to another environment env2 (e.g., development environment). A security policy may be defined for a service group type or for a particular service type.

[0059] In one embodiment, a security policy defines expressions for filtering service groups based on various attributes such that the security policy is applicable to a filtered set of service groups. For example, a security policy may define a list of Internet Protocol (IP) addresses that are whitelisted for a set of service groups identified by the filtered set, such that those computing systems are therefore allowed access to the service groups, or to a particular set of services within the service groups.

[0060] In one embodiment, a security policy may be defined for a service group, a set of source services, and a set of destination services. A source service for a particular service defines services outside of a security group that this particular service can connect to. A destination service for a particular service defines services outside of a security group that this particular service needs to connect to. During provisioning and deployment, the data center creation module generates instructions for the cloud platform that implements the particular network policy using cloud platform specific capabilities and network capabilities, such that the network policy implements the security policy defined in the declarative specification.

[0061] A datacenter entity called a cell represents a set of services that interact with each other in a vertical fashion and can be scaled by additional instances or copies of the cell, i.e. copies of the set of services. Creating multiple instances of a cell allows the system to scale a set of services that interact with each other. A datacenter instance may contain one or more cells. Each cell may contain one or more services. A datacenter may contain service groups or instances of cells.

[0062] A service definition specifies metadata for a type of service, e.g., database service, load balancer service, etc. The metadata describes various attributes of the service, including the name of the service, a description of the service, the location of the documentation for the service, any subservices associated with the service, the owner of the service, the team associated with the service, the build dependencies of the service that specify other services this service depends on when built, the start dependencies of the service that specify other services that should run when this particular service is started, authorized clients, the domain name server (DNS) name associated with the service, the service status, the support level of the service, etc. The service definition specifies a listening port attribute that specifies the ports on which the service can listen for different communication protocols, e.g., a service may listen on port p1 for UDP protocol and port p2 for TCP protocol. Other services in the data center can interact with the service through the ports specified by the service.

[0063] A service definition specifies an attribute outbound access that specifies a destination endpoint, e.g., external URL that specifies that the service requires access to a specified external uniform resource locator (URL). During deployment, the data center generation module ensures that the cloud platform implements the access policy to provide instances of this service type with the required access to the external URL.

[0064] An outbound access specification may identify one or more environment types for the service to which the outbound access is applicable. For example, outbound access to a set of endpoints S1 may apply to a particular environment env1 (e.g., a production environment), and outbound access to a set of endpoints S2 may apply to another environment env2 (e.g., a development environment).

[0065] Below is an example of a service definition.

number

[0066] The team definition 450 includes team member names and other attributes of the team, such as name, email, communication channel, etc. An example of a team definition is as follows: A service may be associated with one or more teams responsible for modifications made to the service. Thus, any modifications made to the service are approved by the team. A service may be associated with a team responsible for maintaining the service after it is deployed in the cloud platform. A team may be associated with a service group and accordingly associated with all services in that service group. For example, the team approves any changes to a service group, e.g., any changes to a service that is part of the service group. A team is associated with a data center and accordingly associated with all service groups in the data center. Team association defined at the data center level provides a default team for all service groups in the data center and further provides a default team for all services in the service group.

[0067] According to one embodiment, team associations defined at the function level override team associations provided at the datacenter level. Similarly, team associations defined at the service level override defaults that may be provided by team associations defined at the service group level or datacenter level. The team can determine how certain actions are taken for the datacenter entities associated with the team. The team association also generates a final metadata representation of the datacenter for the cloud platform by the compiler and determines the number of accounts on the cloud platform that are created for provisioning and deploying the datacenter on the cloud platform. The datacenter generation module 210 creates one or more user accounts in the cloud platform and provides access to the user accounts to the team members. Thus, the team members are enabled to perform certain actions associated with the datacenter entities associated with the team, such as making or approving structural changes to or maintenance of the datacenter entities as they are deployed, including debugging and testing issues that may be identified for the datacenter entities.

[0068] Conventional techniques associate the same team with a datacenter throughout the design process, thereby resulting in an organizational structure that impacts the design of the datacenter and / or service groups. Embodiments decouple team definitions from the constructs that define datacenter entities, thereby reducing the influence that teams have on the design and architecture of datacenter entities.

number

[0069] Environment definition 460 defines the type of system environment presented by the data center, e.g., development environment, staging environment, test environment, production environment. Schema definition 470 defines a schema that defines the syntax of certain data center entity definitions. Schema definition 470 is used to validate various data center entity definitions. The data center generation module determines the security policies of the data center in the cloud platform specific metadata representation based on the environment. For example, a particular set of security policies may be applicable to environment env1 and a different set of security policies may be applicable to environment env2. For example, the security policies provide much more limited access in the production environment compared to the development environment. The security policies may define the length of time that a security token is allowed to exist for a particular purpose. For example, long access tokens (e.g., access tokens over a week) may be allowed in the development environment, while in the production environment, access tokens with a much shorter life span (e.g., a few hours) are used. The access tokens may enable access to particular cloud platform resources for a user or service.

[0070] The datacenter definition 420 specifies attributes and components of a datacenter instance. A declarative specification may specify multiple datacenter instances. The datacenter definition 420 specifies attributes including a name, a description, a type of environment, a set of service groups, a team, domain name servers for the datacenter, etc. The datacenter definition may specify a schema definition, and any metadata representation generated from the datacenter definition is validated against the specified schema definition. A datacenter includes a set of core services and capabilities that enable other services to function within the datacenter. An instance of a datacenter may be deployed on a particular cloud platform and associated with a particular development type, e.g., development, testing, staging, production, etc.

[0071] Below is a definition of a datacenter instance: A datacenter instance definition includes a list of service groups included in the datacenter instance, as well as other attributes including the datacenter's environment, a datacenter identifier, a name, a region representing a geographic region, one or more teams associated with the datacenter, and a schema version.

number

[0072] FIG. 5 illustrates some exemplary data centers created on a cloud platform based on a declarative specification according to one embodiment. The data centers 510 may be created based on the declarative specification processed by the data center generation module 210. As shown in FIG. 5, multiple data centers may be configured in the cloud platform 120. Each data center 510 may correspond to a tenant 115 of the multi-tenant system 110. The tenant 115 may create one or more data centers 510. Alternatively, the data centers 510 may be created by any computing system. Each data center includes one or more service groups. For example, data center 510a includes service groups 520a and 520b, and data center 510b includes service group 520c. A data center may include multiple instances of a particular type of service group. Each service group includes a set of services. For example, service group 520a includes services 530a and 530b, service group 520b includes services 530a, 530b, and 530c, and service group 520c includes services 530e, 530f, and 530g. A service group may include multiple instances of services of the same service type.

[0073] The data center generation module 220 creates a data center in a cloud platform based on a declarative specification using the following steps: The data center generation module 210 receives a cloud platform independent declarative specification of a data center. The cloud platform independent declarative specification may be for a tenant of a multi-tenant system or for any other computing system, e.g., an online system. The cloud platform independent declarative specification is specified using a cloud platform infrastructure language. The cloud platform independent declarative specification of the data center is configured to generate a data center in any of multiple cloud platforms.

[0074] The data center creation module 210 receives information identifying a target cloud platform for creating a data center based on the cloud platform independent declarative specification. The target cloud platform can be any of a number of cloud platforms, for example, AWS, AZURE, GCP, etc. The data center creation module 210 further receives information for connecting with the target cloud platform, for example, credentials for creating a connection with the target cloud platform. The cloud platform may also be referred to as a cloud computing platform.

[0075] The data center generation module 210 compiles the cloud platform independent declarative specification to generate a cloud platform specific data center representation for creating a data center in a target cloud platform. For example, the cloud platform specific data center representation may refer to user accounts, network addresses, etc. specific to the target cloud computing platform.

[0076] The data center generation module 210 sends the platform-specific data center representation along with instructions for deploying the data center to a target cloud computing platform. The target cloud computing platform executes the instructions to configure computing resources of the target cloud computing platform to generate a data center according to the platform-specific data center representation. The data center generation module 210 provides users with access to the computing resources of the data center configured by the cloud computing platform. For example, if a data center is created for a tenant of a multi-tenant system, users associated with the tenant are provided with access to the data center.

[0077] 6 is a block diagram illustrating the generation of a data center on a cloud platform based on a declarative specification, according to one embodiment. The data center generation module 210 receives as input a cloud platform independent declarative specification 610. The cloud platform independent declarative specification 610 may be a version of a declarative specification that is incrementally modified by a user. The data center generation module 210 processes a specific version of the cloud platform independent declarative specification 610. Because the cloud platform independent declarative specification 610 is not specified for any particular target cloud platform, the data center generation module 210 can configure a data center on any target cloud platform based on the cloud platform independent declarative specification 610.

[0078] The data center generation module 210 processes the cloud platform independent declarative specification 610 to generate a cloud platform independent detailed metadata representation 620 for the data center. The cloud platform independent detailed metadata representation 620 defines details of each instance of a data center entity identified in the cloud platform independent declarative specification 610. The data center generation module 210 creates a unique identifier for the data center entity instance, e.g., a service instance.

[0079] In one embodiment, the cloud platform independent detailed metadata representation 620 includes an array of instances of a data center entity type, e.g., an array of service group instances of a particular service group type. Each service group instance includes an array of service instances. The service instances may further include details of a team of users that are enabled to perform specific actions associated with the service instance. The team details are used during provisioning and deployment by the data center creation module 210, for example, to create user accounts for the service instance and enable members of the team to access the user accounts.

[0080] The cloud platform independent detailed metadata representation 620 includes attributes of each instance of the data center entity. Thus, the description of each instance of the data center entity is expanded to include all details. As a result, the cloud platform independent detailed metadata representation 620 of the data center may be significantly larger than the cloud platform independent declarative specification 610. For example, the cloud platform independent declarative specification 610 may be thousands of lines of specification, whereas the cloud platform independent detailed data center representation 620 may be millions of lines of generated code. As a result, the data center generation module 210 maintains the cloud platform independent detailed metadata representation 620 as immutable, i.e., once the representation is finalized, no modifications are performed to the representation. For example, if any updates, deletions, or additions of data center entities need to be performed, they are performed to the cloud platform independent declarative specification 610.

[0081] The data center generation module 210 receives a target cloud platform where the data center is expected to be provisioned and deployed, and generates a cloud platform specific detailed metadata representation 630 of the data center. For example, the data center generation module 210 interacts with the target cloud platform to generate specific entities (or resources), e.g., user accounts, virtual private clouds (VPCs) and subnets on the VPCs, networking resources, such as various connections between entities in the cloud platform, etc. The data center generation module 210 receives resource identifiers of resources created in the target cloud platform, e.g., user account names, VPC IDs, etc., and incorporates these into the cloud platform independent detailed metadata representation 620 to obtain a cloud platform specific metadata representation 630 of the data center. In one embodiment, the data center generation module 210 creates one unique user account on the cloud platform for each team for a given combination of service group and service. The user account is used by the team to perform interactions with that particular service for that service group, e.g., for debugging, receiving alerts, etc.

[0082] The target cloud platform may perform several steps to process the cloud platform specific detailed metadata representation 630. For example, the cloud platform independent declarative specification may specify permitted interactions between services. These permitted interactions are specified in the cloud platform specific detailed metadata representation 630 and implemented as network policies of the cloud platform. The cloud platform may further create security groups that implement a network strategy for implementing the data center according to the declarative specification.

[0083] The cloud platform independent declarative specification specifies dependencies between services. For example, start dependencies for each service list all services that should run when a particular service is started. The data center generation module 220 generates a cloud platform specific detailed metadata representation of the data center that includes information describing these dependencies, so that the instructions for deploying the services ensure that the cloud platform starts the services in the order specified by the dependencies, such that, for each service, those services are required to be started before the service runs when the service is started. Thus, the dependencies between services represent a dependency graph, and start the execution of the services in an order determined based on the dependency graph, so that if service A depends on service B, service B is started before service A is started.

[0084] The data center generation module 220 creates trust relationships between user accounts that allow services to access other services over a secure communication channel. These trust relationships are generated based on the declarative specification, e.g., using substrate-specific instructions generated based on outbound access attributes defined for the services. The data center generation module 220 sends instructions to the cloud platform to create network policies based on cloud platform-specific mechanisms that control interactions and access across service groups and services, as defined by constructs in the declarative specification, e.g., outbound access, security groups, security policies, etc.

[0085] The data center generation module 210 deploys the cloud platform specific metadata representation 630 to the particular target cloud platform for which the representation was generated. The data center generation module 210 may use the generated metadata representation to perform various validations, including policy validation, format validation, etc.

[0086] The cloud platform independent declarative specification 610 is referred to as a declared data center representation, the cloud platform independent detailed metadata representation 620 is referred to as a derived metadata representation of the data center, and the cloud platform specific metadata representation 630 is referred to as a hydrated metadata representation of the data center.

[0087] 7 illustrates an overall process for generating a pipeline for deploying software artifacts to a datacenter configured on a cloud platform, according to one embodiment. A datacenter generation module generates one or more datacenters in a target cloud platform (710). Each datacenter is generated from a cloud platform independent declarative specification and has a hierarchy of datacenter entities.

[0088] The software release management module generates (720) a cloud platform agnostic master pipeline. In one embodiment, the cloud platform agnostic master pipeline includes stages corresponding to environments of the data center, e.g., development, test, canary, and production environments. The master pipeline configures a sequence of staged and / or conditional deployments across various environments, such as development, test, staging, or production environments. The master pipeline includes stages or instructions for deploying builds in environments of type development, triggered by delivery of an image of the software artifact. The built software artifact is conditionally promoted to one or more test environments, followed by one or more canary environments before finally being deployed to a production environment. The master pipeline may be customized by a user, e.g., a service owner, to represent a specific orchestration between environments. The master pipeline may be customized to capture specific promotion criteria for moving from one stage to the next. For example, different tenants of a multi-tenant system may customize the master pipeline in different ways. In one embodiment, the master pipeline by default uses the latest version of software for software artifacts for services and builds and deploys that version across various environments. Users can use artifact version maps to ensure that specific versions of software artifacts are deployed to specific data center entities.

[0089] In one embodiment, each service deployed in a data center has a cloud platform agnostic master pipeline generated from data center entities defined by the declarative specification of the data center, e.g., a master pipeline for a data center instance, a master pipeline for a service group, a master pipeline for a cell, a master pipeline for a service, etc. The master pipeline may be triggered upon delivery of an image of a software artifact. The master pipeline may implement a service owner controlled continuous deployment. The master pipeline may implement a data center instance owner owned or release owner owned on-demand deployment.

[0090] Certain portions of the master pipeline may be customized by users, e.g., tenants of a multi-tenant system deploying services in a data center. For example, the promotion decision pipeline may be customized by a tenant to determine which test cases are executed and which thresholds are executed. The software release management module 230 receives 730 customizations to the logic for promoting software artifacts from one stage of the cloud platform independent master pipeline to another stage.

[0091] The software release management module 230 compiles the cloud platform agnostic master pipeline to generate cloud platform specific detailed deployment pipelines that are specific to each data center's hierarchy of data center entities as specified by the cloud platform agnostic declarative specification for the data center (740).

[0092] The software release management module 230 further receives (750) code for releasing one or more features of the service deployed to the data center. The software release management module 230 executes a cloud platform specific detailed deployment pipeline to deploy (760) software artifacts based on the received code.

[0093] FIG. 8 illustrates an exemplary master pipeline 800, according to one embodiment. The master pipeline represents a sequence of stages representing a staged conditional deployment across various data center environments. FIG. 8 illustrates stages for different environments in a data center, including development, test, canary, and production environments. Each stage further represents the pipeline that is executed for that stage. Thus, the master pipeline 800 includes a development environment pipeline 810 that feeds a test environment pipeline 820, which feeds a canary environment pipeline 840, which feeds a production environment pipeline 830.

[0094] Each stage pipeline is a hierarchical pipeline that contains lower level pipelines, for example, development environment pipeline 810 includes a development master pipeline that feeds data center pipelines D11, D12, ... depending on the number of data centers defined in the data center declarative specification as having development environments.

[0095] For example, test environment pipeline 820 includes a test master pipeline that feeds data center pipelines D21, D22, . . . depending on the number of data centers defined in the data center declarative specification as having test environments.

[0096] For example, the canary environment pipeline 820 includes a canary master pipeline that feeds data center pipelines D31, D32, ... depending on the number of data centers defined in the data center declarative specification as having a canary environment.

[0097] For example, the production environment pipeline 820 includes a production master pipeline that feeds data center pipelines D21, D22, . . . depending on the number of data centers defined in the data center declarative specification as having test environments.

[0098] Each environment pipeline 810, 820, 830 includes a promote decision pipeline 815a, 815b, 815c, respectively. The output of the data center pipelines of the environment pipelines is collected by a promote decision pipeline 815, which determines whether the software artifact is ready for promotion to the next stage. The promote decision pipeline 815 may determine whether the software artifact for the service is to be promoted to the next stage based on the test case results obtained by the data center. For example, if more than a threshold number of test cases pass, the promote decision pipeline 815 promotes the software artifact to the next stage. The last environment stage, e.g., the production environment pipeline, may not have a promote decision pipeline because there are no subsequent stages to which the software artifact needs to be promoted. As shown in FIG. 8, the promotion decision pipeline 815a of the development environment pipeline determines whether to promote a software artifact from a development stage to a test stage, the promotion decision pipeline 815b of the test environment pipeline determines whether to promote a software artifact from the test stage to a canary stage, and the promotion decision pipeline 815c of the canary environment pipeline determines whether to promote a software artifact from the canary stage to a production stage.

[0099] The master pipeline includes multiple pipelines, such as a provisioning pipeline for provisioning resources of a target cloud platform and a deployment pipeline for deploying software artifacts to data center entities. Each pipeline includes a sequence of stages, and each stage represents one or more actions that need to be performed by the target cloud platform for data center provisioning and deployment. The data center generation module 210 generates detailed pipelines for deploying versions of software artifacts on data center entities.

[0100] In one embodiment, the pipeline generation module 320 generates a detailed pipeline using a pipeline template that includes variables. The pipeline template is converted into a pipeline by providing specific values ​​for the variables to the pipeline. The process of generating a pipeline from a template is called hydrating the pipeline template. The pipeline template includes template expressions that are used as placeholders for actual values ​​used in deployment. For example, the template expressions may be replaced by specific parameter values ​​or expressions of a goal. Multiple pipeline instances may be generated by hydrating the pipeline template for different goals. The template variables represent parameters that may be replaced with specific values ​​for a given goal to generate a pipeline instance specific to that goal. For example, the template variable "account_id" may be replaced with the actual value of "account_id" during hydration, e.g., "12345".

[0101] In one embodiment, the pipeline generation module 320 generates pipelines in a hierarchical manner based on a hierarchy of data center entities for a data center. For example, a data center includes different types of data center entities including data centers, service groups, services, etc. A data center entity may include one or more child data center entities. For example, a data center includes one or more service groups as child data center entities. A service group includes one or more services as child data center entities. Thus, the data center generation module 210 starts with a data center entity at a level of the hierarchy and generates pipelines for data center entities below that level. For example, the pipeline generation module 320 starts with a data center and generates pipelines for service groups in the data center. For each service group, the pipeline generation module 320 generates pipelines for the services in the service group.

[0102] A process for executing a pipeline according to one embodiment is as follows: The software release deployment module 230 receives a request to deploy a software artifact to a set of data center entities in a target cloud platform. The software release deployment module 230 executes a master pipeline for one or more data centers. The software release deployment module 230 executes an aggregation pipeline for each service group in each data center. The aggregation pipeline includes pipelines for the services in the service groups. The pipeline is executed by executing all stages of the pipeline for each service in each service group. The provisioning pipeline executes, which results in the provisioning of resources for the service, and the deployment pipeline results in the deployment of the service in the target cloud platform.

[0103] Figure 9 illustrates the overall process performed by stages for an environment of a master pipeline on a cloud platform, according to one embodiment. Steps 910, 920, 930, 940, and 950 may be performed by each environment pipeline 810, 820, 830. The production environment pipeline 3 may only perform steps 910 and 920. The steps illustrated in Figure 9 may be performed for one service or multiple services defined using a manifest file.

[0104] The environment pipeline for environment E includes instructions to deploy 910 software to a set of datacenter entities, e.g., the set of datacenter entities defined as having environment E. In one embodiment, the software artifacts are generated by compiling source code for the services. The source code may be obtained from version control software. The set of datacenter entities may include datacenter instances, service groups, cells, services, or any combination thereof.

[0105] The environment pipeline for environment E further includes instructions for executing tests (920) to test the software artifacts deployed to the set of data center entities. The environment pipeline for environment E further includes instructions for evaluating test results (930) against promotion criteria, e.g., using the promotion decision pipeline 815. If the promotion criteria are not met, steps 910, 920, 930, and 940 may be repeated using a modified software artifact, e.g., a software artifact generated from source code that includes a fix for a particular defect identified during testing 920. The environment pipeline for environment E further includes instructions for proceeding to the next stage (950) if the promotion criteria are met.

[0106] In one embodiment, the master pipeline includes a hierarchy of pipelines. The hierarchy includes multiple levels, and a pipeline at a particular level includes the pipelines at the next lower level as child pipelines. For example, at the top level of the hierarchy, the master pipeline includes a release master pipeline that deploys a set of services related to a product. The next level of the hierarchy includes a service master pipeline that represents all deployments of a particular service across various environments. The next level of the hierarchy includes a service group master pipeline, followed by a service master pipeline.

[0107] FIG. 10 illustrates an exemplary master pipeline, according to one embodiment. The master pipeline is a hierarchical pipeline where each stage of the pipeline may include a pipeline with detailed instructions for executing that stage. The master pipeline hierarchy may mirror the data center hierarchy. For example, the top level of the master pipeline represents a sequence of stages for different environments. Each environment may include one or more pipelines for a data center instance or pipelines for other types of data center entities. The data center instance pipelines 1010 may include a service group pipeline 1020. Each service group pipeline 1020 may include one or more service pipelines 1030. The data center instance pipelines 1010 may include a cell pipeline 1025, each cell pipeline 1025 includes one or more service pipelines 1030. The service pipelines 1030 may include stages, each stage representing a pipeline that represents instructions for deploying a service for a particular environment. The lowest level or leaf level pipelines in the hierarchy are called unit pipelines and may include detailed service-specific instructions for performing operations related to the service. For example, a deployment for a service may include pre-deployment steps, deployment steps, post-deployment steps, and post-deployment testing and validation steps. A pipeline that has one or more child pipelines rather than a leaf-level pipeline is an aggregate pipeline that orchestrates the execution of the child pipelines.

[0108] The master pipeline may be driven by a pull request that causes a version control system for software to receive a request to consider changes committed to an external repository for inclusion in the project's main repository. Thus, the master pipeline is automatically triggered when a pull request is received and deploys software artifacts based on the latest software version for which the pull request is received. The master pipeline performs continuous delivery of software artifacts based on pull requests. The master pipeline may be driven on an on-demand basis, for example, by invoking requests using an application programming interface (API) of the deployment module 210. On-demand deployment based on the master pipeline may be requested for any set of services and any version for a given service, as specified using the API. The master pipeline may be invoked to request a rollback from a current version to a previous version, or a rollforward from a currently deployed version to a more recent version.

[0109] In one embodiment, the deployment module 210 creates a service master pipeline for each service. These pipelines are triggered when a pull request for the software repository is received. The deployment module 210 receives pipeline templates from users for specific services. These pipeline templates include detailed descriptions of testing, validation, builds, etc. for the specific services. The data center creation module 220 receives cloud platform independent declarative specifications for one or more data centers. The data center creation module 220 creates (or configures) the data centers according to the received cloud platform independent declarative specifications. The deployment module 210 receives a promotion decision pipeline 815. The promotion decision pipeline 815 is integrated into the overall master pipeline.

[0110] The pipeline generator creates all the pipelines for each data center from the template and combines them hierarchically through the master pipeline, for example as illustrated in Figure 10. In one embodiment, the pipeline generator generates service pipelines for individual services, the pipeline generator generates cell master pipelines to call the service pipelines, the pipeline generator generates service group master pipelines to call the cell master pipelines, the pipeline generator generates data center instance master pipelines to call the service group pipelines, and the pipeline generator generates service master pipelines to call the data center instance master pipelines.

[0111] Below is a snippet of a master pipeline showing the various stages. Each stage may define attributes including the stage name, the type of pipeline, the stage type (e.g., master deploy pipeline or promote pipeline), previous stage, etc.

number

[0112] As shown in the Examina Master Pipeline, the first stage is the Artifact Version Map. The next stage is the Master Deploy Pipeline for deploying to a Development environment. The next stage is the Promote Pipeline for determining if the software artifact can be promoted to the next stage, which is a Test environment. The next stage is the Promote Pipeline for determining if the software artifact can be promoted to the next stage, which is a Stage environment. Software Artifact Version Map

[0113] In one embodiment, the deployment module 210 receives an artifact version map that associates various software artifacts and their versions with data center entities. The artifact version map provides a declarative specification of the specific versions of software artifacts that need to be deployed for a service at different data center entities. Each data center entity may be uniquely identified based on its location in the data center hierarchy as specified by the declarative specification of the data center. For example, in a service, a software library may act as a software artifact. A software artifact may have multiple versions, e.g., V1, V2, V3, etc. The artifact version map may specify that version V1 needs to be deployed to data center entities C1 and C2, and version V2 needs to be deployed to data center entities C3 and C4. The deployment module 210 generates master pipelines and instructions that ensure that the appropriate software artifact versions are deployed at the data center entities as specified in the artifact version map.

[0114] In one embodiment, the artifact version map is defined as a Javascript object notation (JSON) file, a YAML file, or a file using any other syntax for representing nested objects. The artifact version map is associated with various data center entities distributed across a hierarchy of data centers. <service> : <version>An artifact version map may contain a set of key pairs. The artifact version map key pair acts as a whitelist for the corresponding pipeline. If a service's key is not included in the artifact version map, all pipelines for that service will be excluded during pipeline execution. Different artifact version maps applied to the same master pipeline may result in different services being included / excluded during master pipeline execution.

[0115] Below is an example artifact version map. The artifact version map specifies an environment type using the attribute "env_types". In the example below, an environment type development is specified. An environment type may include one or more data center instances, which may include one or more service groups, which may include one or more services. In the example below, a software artifact name is specified as library1 and a version as version1, which is associated with a service instance instance001. However, the software artifact name and version may be associated with a data center entity at any level in the hierarchy. For example, if a software artifact name and version is specified, or in the case of a service group, the software artifact name and version are applicable to all services in the service group unless overridden with a different value of the software artifact name and version specified for a particular service instance in the service group. Similarly, a software artifact name and version may be specified for a data center instance and is applicable to all service groups or cells in the data center instance, unless an override value is specified for the service group.

number

[0116] In one embodiment, the artifact version map defines a datacenter entity using a full path of the datacenter entity, e.g., "stagger_group1 / datacenter1 / service_group2 / service1." In one embodiment, the artifact version map defines a set of datacenter entities using regular expressions in the full path of the datacenter entity. For example, a full path that includes service_group[?] includes service_group1, service_group2, service_group3, etc.

[0117] Below is an example of an artifact version map that specifies a regular expression that defines a set of services. The environment types are specified as dev and test, the datacenter entity is specified with a wildcard in the full path including the datacenter instance and the service group, and the service instance is specified as "service*". Therefore, version V1 of application app1 will be deployed to all datacenter instances for development and test environments, for all service groups, and for service names that match service*.

number

[0118] In some embodiments, an artifact version map may specify parameters that are used by the pipeline such that the specified parameters apply to the stagger group for which they are specified.

[0119] FIG. 11 illustrates an exemplary master pipeline for a data center, according to one embodiment. As illustrated in FIG. 11, the master pipeline runs on a deployment group (also called a stagger group), which refers to a collection of data center entities defined by a declarative specification. An artifact version map may specify a stagger group attribute to define a set of data center entities that may be associated with a particular artifact version. A data center entity may be identified by specifying a path from a root node in a hierarchy of a data center, e.g., a data center instance. As illustrated in FIG. 11, the master pipeline defines various stages for different environments. Each stage performs an action on a set of data center entities, called a deployment group 1110. 11 shows a development deployment group 1110a including data center entities including service groups S11, S12, and S13, a test deployment group 1110b including data center entities including service groups S21, S22, and S23, and a production deployment group 1110b including data center entities including service groups S31, S32, S33, and S34. Results of tests on the data center entities of the development deployment group 1110a are evaluated (1120a) to determine whether software artifacts tested in the development deployment group 1110a should be promoted to the test deployment group 1110b. Similarly, results of tests on the data center entities of the test deployment group 1110a are evaluated (1120b) to determine whether software artifacts tested in the test deployment group 1110a should be promoted to the production deployment group 1110c.

[0120] FIG. 12 illustrates how the execution of a master pipeline is modified based on an artifact version map, according to one embodiment. The artifact version map associates versions of software artifacts with data center entities. The system modifies the detailed pipelines executed on the data center entities to ensure that actions associated with the appropriate version of the software artifact are executed on each data center entity. For example, FIG. 12 shows versions V1 and V2 of a software artifact for service SVC1. Version V1 is associated with service groups S11, S23, and S31, and version V2 is associated with service groups S11, S21, and S32. Assume that the master pipeline is deploying a version of service SVC1 to a data center. Thus, the system modifies the executed pipeline to deploy version V1 to service groups S11, S23, and S31, and version V2 to service groups S11, S21, and S32. In one embodiment, the system introduces a version map filter before the stage of the master pipeline shown in FIG. 11. The execution of the master pipeline selects a version of the software artifact for each data center entity based on a version map filter. For example, the version map filter includes instructions to skip service groups S13, S22, S33, and S34 for this particular action. The version map filter specifies that version V1 is deployed to service groups S11, S23, and S31, and version V2 is deployed to service groups S11, S21, and S32.

[0121] 13 illustrates an overall process for deploying software artifacts to a data center configured on a cloud platform, according to one embodiment. A data center generation module generates 1310 one or more data centers in a target cloud platform. Each data center is generated from a cloud platform independent declarative specification and has a hierarchy of data center entities.

[0122] The software release management module 230 receives as input an artifact version map that maps data center entities to versions of software artifacts. The software release management module 230 also receives 1330 a cloud platform agnostic master pipeline as input.

[0123] The software release management module 230 compiles the cloud platform agnostic master pipeline along with the artifact version map to generate 1340 a cloud platform specific detailed pipeline. In one embodiment, the generated cloud platform specific detailed pipeline includes an artifact version map filter before a particular stage to determine whether the particular stage should be enabled or disabled according to the artifact version map.

[0124] The software release management module 230 further receives (1350) code for releasing one or more features of the service deployed to the data center. For example, the code may represent source code obtained from a version control management system that stores a source code repository to which changes are submitted by developers. The software release management module 230 executes a cloud platform-specific deployment pipeline to deploy software artifacts based on the received code (1360).

[0125] The artifact version map and master pipeline may be used to orchestrate various types of operations related to continuous delivery of software artifacts in a cloud-based data center. The artifact version map and master pipeline may be configured to perform aggregate retry operations for a service, a service group, or any data center entity. The artifact version map includes configuration of retry operations for a data center entity, such as a retry strategy, a threshold number of retries to perform if a stage of the pipeline fails to execute, whether confirmation from a user is required before retrying, and whether a retry is performed automatically. For example, the retry strategy may be a fixed backoff strategy that pauses execution for a period of time before retrying. Other retry strategies may be configured using the artifact version map and master pipeline. In one embodiment, the pipeline generator introduces a call retry stage in the aggregate pipeline to trigger the retry strategy if a previous pipeline stage fails. The retry strategy and configuration parameters defined for a data center entity apply to all data center entities and services within the data center entity unless the values ​​are overridden for a nested data center entity. Computer Architecture

[0126] 14 is a high-level block diagram illustrating a functional view of a typical computer system for use as one of the entities illustrated in the environment 100 of FIG. 1, according to one embodiment. Illustrated is at least one processor 1402 coupled to a chipset 1404. Also coupled to the chipset 1404 are memory 1406, a storage device 1408, a keyboard 1410, a graphics adapter 1412, a pointing device 1414, and a network adapter 1416. A display 1418 is coupled to the graphics adapter 1412. In one embodiment, the functionality of the chipset 1404 is provided by a memory controller hub 1420 and an I / O controller hub 1422. In another embodiment, the memory 1406 is coupled directly to the processor 1402 instead of the chipset 1404.

[0127] The storage device 1408 is a non-transitory computer-readable storage medium, such as a hard drive, a compact disc read-only memory (CD-ROM), a DVD, or a solid-state memory device. The memory 1406 holds instructions and data used by the processor 1402. The pointing device 1414 may be a mouse, a trackball, or other type of pointing device and is used in combination with the keyboard 1410 to input data into the computer system 200. The graphics adapter 1412 displays images and other information on the display 1418. The network adapter 1416 couples the computer system 1400 to a network.

[0128] As is known in the art, computer 1400 may have different and / or other components than those depicted in Figure 14. Additionally, computer 1400 may lack certain illustrated components. For example, a computer system 1400 operating as a multi-tenant system 110 may lack a keyboard 1410 and a pointing device 1414. Furthermore, storage device 1408 may be local and / or remote from computer 1400 (e.g., embodied in a storage area network (SAN)).

[0129] The computer 1400 is adapted to execute computer modules for providing the functions described herein. As used herein, the term "module" refers to computer program instructions and other logic for providing a particular function. A module may be implemented in hardware, firmware, and / or software. A module may include one or more processes and / or may be provided by only a portion of a process. A module is typically stored on the storage device 1408, loaded into the memory 1406, and executed by the processor 1402.

[0130] The type of computer system 1400 used by the entities of the system environment can vary depending on the embodiment and the processing power used by the entities. For example, a client device may be a mobile phone with limited processing power, a small display 1418, and may lack a pointing device 1414. In contrast, a multi-tenant system or cloud platform may include multiple blade servers that work together to provide the functionality described herein. Additional Considerations

[0131] The particular naming of components, capitalization of terms, attributes, data structures, or other programming or structural aspects are not required or important, and mechanisms for implementing the described embodiments may have different names, formats, or protocols. Further, the systems may be implemented through a combination of hardware and software as described, or entirely with hardware elements. Also, the particular division of functionality between various system components described herein is merely exemplary and not required, and functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.

[0132] Some portions of the above description are presented in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, will be understood to be implemented by computer programs. Further, it has proven convenient at times, without loss of generality, to refer to arrangements of these operations as modules or by functional names.

[0133] As will be apparent from the above description, unless otherwise specifically stated, throughout this specification, descriptions utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," and the like, are understood to refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities in the computer system memory or registers, or other such information storage, transmission or display device.

[0134] Certain embodiments described herein include process steps and instructions that are described in the form of an algorithm. It should be noted that the process steps and instructions of the embodiments may be embodied in software, firmware or hardware, and when embodied in software, may reside on and operate from different platforms that are downloaded and used by a real-time network operating system.

[0135] The described embodiments also relate to an apparatus for performing the operations herein. The apparatus may be specially constructed for the required purposes or may include a general-purpose computer selectively initiated or reconfigured by a computer program stored on a computer-readable medium that can be accessed by the computer. Such computer programs may be stored on non-transitory computer-readable storage media, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus. Furthermore, the computers referred to herein may include a single processor or may be architectures employing multiple processor designs to increase computing power.

[0136] The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may be convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems, along with equivalent variations, will be apparent to those skilled in the art. Additionally, the present embodiments are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​may be used to implement the teachings of the embodiments as described herein.

[0137] Embodiments are well suited to a wide variety of computer network systems across numerous topologies, including configuration and management of large networks including storage devices and computers communicatively coupled to dissimilar computers and storage devices over networks such as the Internet.

[0138] Finally, it should be noted that the language used herein has been chosen primarily for ease of reading and instructional purposes, and not to delineate or delimit inventive subject matter. Accordingly, the disclosure of embodiments is intended to be illustrative, but not limiting.< / version> < / service>

Claims

1. 1. A computer-implemented method for deploying software artifacts of a service that runs in a data center configured on a cloud platform, comprising: Accessing a data center configured in a target cloud platform, the data center being generated based on a cloud platform independent declarative specification including a hierarchy of data center entities, each data center entity including one or more of: (1) a service; or (2) one or more other data center entities; receiving a cloud platform independent artifact version map that associates data center entities of the data center with versions of software artifacts targeted for deployment to the data center entities, each software artifact including executable instructions associated with a service configured to run on one or more cloud platforms; generating a cloud platform specific deployment pipeline for the target cloud platform based on the cloud platform independent artifact version map, the cloud platform specific deployment pipeline including instructions for building and deploying appropriate versions of deployment artifacts for the service on the data center entity according to the cloud platform independent artifact version map; and sending the cloud platform specific deployment pipeline to the target cloud platform for execution.

2. generating a cloud platform agnostic deployment pipeline including instructions for building and deploying software artifacts to the data center; The computer-implemented method of claim 1 , further comprising compiling the cloud platform agnostic deployment pipeline in conjunction with the cloud platform agnostic artifact version map.

3. 3. The computer-implemented method of claim 2, wherein the cloud platform agnostic deployment pipeline includes a version map filter prior to one or more stages, such that execution of a master pipeline causes a version of the software artifact to be selected for each data center entity based on the version map filter.

4. receiving the cloud platform independent declarative specification; The computer-implemented method of claim 1 , further comprising: compiling the cloud platform independent declarative specification to generate a cloud platform specific representation of a data center.

5. Compiling the cloud platform independent declarative specification includes: generating a first version of a cloud platform independent detailed metadata representation of the data center from an original declarative specification; and generating a second version of the cloud platform independent detailed metadata representation of the data center from the modified declarative specification.

6. generating a platform-specific detailed metadata representation for the target cloud platform based on the first version of the cloud platform independent detailed metadata representation; The computer-implemented method of claim 5 , further comprising: deploying the data center on the target cloud platform based on the platform-specific detailed metadata representation.

7. 7. The computer-implemented method of claim 1, wherein the cloud platform independent declarative specification includes a definition of one or more data center instances, each data center instance including one or more service groups, each service group including a set of services.

8. 8. The computer-implemented method of claim 1, wherein the generated instructions include one or more pipelines, each pipeline including a sequence of stages, each stage performing one or more actions for deploying software artifacts to the data center entities.

9. A non-transitory computer readable storage medium for storing instructions which, when executed by a computer processor, cause the computer processor to perform the method of any one of claims 1 to 8.

10. 1. A computer system comprising: A computer processor; A non-transitory computer readable storage medium for storing instructions which, when executed by a computer processor, cause the computer processor to perform any one of claims 1 to 8.

11. 1. A computer-implemented method for deploying software artifacts of a service that runs in a data center configured on a cloud platform, comprising: Accessing a data center configured in a target cloud platform, the data center being generated based on a cloud platform independent declarative specification including a hierarchy of data center entities, each data center entity including one or more of: (1) a service; or (2) one or more other data center entities; generating a cloud platform agnostic master deployment pipeline including a sequence of stages for deploying a software artifact, the sequence of stages including one or more of a development stage, a test stage, and a production stage, at least some of the stages of the sequence defining criteria for promoting the software artifact from the stage of the sequence to a subsequent stage of the sequence; compiling the cloud platform independent master deployment pipeline to generate a cloud platform dependent detailed deployment pipeline for the target cloud platform with instructions for deploying services according to a datacenter layout defined by the cloud platform independent declarative specification; and deploying software artifacts for one or more services by executing the cloud platform dependent detailed deployment pipeline on the target cloud platform.

12. 12. The computer-implemented method of claim 11, further comprising receiving information for customizing the cloud platform independent master deployment pipeline, wherein the cloud platform dependent detailed deployment pipeline for the target cloud platform is generated for the customized cloud platform independent master deployment pipeline.

13. 13. The computer-implemented method of claim 12, wherein the information for customizing the cloud platform agnostic master deployment pipeline modifies the criteria for promoting the software artifacts from a first stage of the sequence to a second stage of the sequence.

14. The computer-implemented method of any one of claims 11 to 13, further comprising providing a user with access to the services running in a data center deployed in the target cloud platform.

15. 15. The computer-implemented method of claim 11, wherein the cloud platform independent master deployment pipeline includes a hierarchy of pipelines having a hierarchical structure corresponding to a hierarchy of the data center entities defined by the cloud platform independent declarative specification.

16. 20. The computer-implemented method of claim 15, wherein the hierarchy of pipelines includes a data center instance pipeline that includes one or more service group pipelines, the service group pipelines including one or more service pipelines.

17. receiving the cloud platform independent declarative specification; The computer-implemented method of any one of claims 11 to 16, further comprising: compiling the cloud platform independent declarative specification to generate a cloud platform specific representation of a data center.

18. Compiling the cloud platform independent declarative specification includes: generating a first version of a cloud platform independent detailed metadata representation of the data center from an original declarative specification; and generating a second version of the cloud platform independent detailed metadata representation of the data center from the modified declarative specification.

19. generating a platform-specific detailed metadata representation for the target cloud platform based on the first version of the cloud platform independent detailed metadata representation; 20. The computer-implemented method of claim 18, further comprising: deploying the data center on the target cloud platform based on the platform-specific detailed metadata representation.

20. 20. The computer-implemented method of claim 11, wherein the cloud platform independent declarative specification includes a definition of one or more data center instances, each data center instance including one or more service groups, each service group including a set of services.

21. A non-transitory computer readable storage medium for storing instructions which, when executed by a computer processor, cause the computer processor to perform any one of claims 11 to 20.

22. 1. A computer system comprising: A computer processor; A non-transitory computer readable storage medium for storing instructions which, when executed by a computer processor, cause the computer processor to perform the method of any one of claims 11 to 20.

Images