UNIFIED VIRTUALIZED AND CONTAINERIZED CI/CD CHAIN

Examples of the present technology provide automated CI/CD systems that unify the CI/CD methodology for virtualized and containerized software environments. To realize this unification, CI/CD systems of the present technology are intelligently designed to leverage a common set of inputs (i.e., artifacts and deployment descriptors) that can facilitate automatic deployment of the software system in either a virtualized environment, a containerized environment, or both. Accordingly, CI/CD systems of the present technology provide a flexible software development tool that facilitates efficient, and automated deployment of software systems in both virtualized and containerized environments.

BACKGROUND

Continuous Integration/Continuous Deployment (CI/CD) is a software development methodology that involves iterative/continuous integration, testing, and deployment of code for a software system. For example, during a Continuous Integration (CI) stage (sometimes referred to as a CI chain), members of a software development team can publish source code of a software system they are working on to a shared code repository on a frequent (e.g., daily) basis. A CI/CD system (e.g., one or more software programs, APIs, etc.) can automatically integrate/build the code published to the code repository and test it in a rapid manner—thereby identifying (and in some cases, remedying) bugs and other issues early and often. In a Continuous Deployment (CD) stage (sometimes referred to as a CD chain), the CI/CD system can automatically deploy tested/validated code of the software system in a software environment (e.g., a virtualized or containerized software environment)—thereby making the software system (and any associated updates to the software system) available to end users in a rapid manner. The CI/CD can also run functional tests that ensure an end-to-end version of the software system runs properly. In some cases, instead of, or in addition to the Continuous Deployment stage, the CI/CD methodology may include a Continuous Delivery (i.e., another version of the “CD”) stage where the CI/CD system automatically deploys tested/validated code of the software system in production-like software environments for further testing/quality assurance before (often human-approved) release to end users.

Computerized CI/CD systems (sometimes referred to herein as CI/CD systems, or CI/CD chains) can significantly reduce the time required to develop, update, and deploy software systems. These advantages can be associated with a CI/CD system's ability to rapidly integrate and test source code, and rapidly/seamlessly deploy tested/validated source code in new or updated software systems. This can improve functioning of the software systems themselves, and the computing devices on which the software systems are run.

DETAILED DESCRIPTION

The Telecom industry generally follows Information Technology (IT) trends. A recent trend in the IT industry has been a migration from virtualized software infrastructure to containerized software infrastructure (sometimes referred to as Cloud Native infrastructure). It is likely that the Telecom industry will follow suit. For example, containerization is foreseeable for the 5G standard based in part on 5G's service-based architecture.

However, a migration from virtualized software infrastructure to containerized software infrastructure presents significant challenges for the Telecom industry (and other industries) due in part to the sheer amount of legacy software/equipment that was not designed to run containerized workloads. For example, while Communication Service Providers (CSPs) promote 5G to the consumer market, many of their networks include a large amount of equipment (and associated software) designed to support previous generations. Often, this legacy equipment/software leverages virtualized software environments.

Legacy Telecom equipment/software (typically dated from the “Application Server era,” with associated massive monolithic software bundling many functionalities) is not likely to be replaced because of associated risk and a limited benefit vs. cost ratio for CSPs. However, assuming the Telecom industry migrates to containerized infrastructure as expected—such legacy Telecom equipment/software will likely migrate to containerization in order to operate with new equipment/software designed around containerization from day one. Aside from potential performance/reliability issues associated with utilizing containerization for legacy Telecom equipment/software not designed to support such functionality—such a scenario can also impose constraints on the software deployment process. For example, designing software systems that can be containerized on the application servers of legacy Telecom equipment presents unique challenges. For example (and as alluded to above), such legacy Telecon equipment/software may be associated with massive monolithic software bundling many functionalities. Each functionality may be a self-contained component having its own life cycle—which can make the process of constructing containerized workloads (e.g., generation of container images) exceedingly complex. These challenges are amplified by differences across legacy Telecom equipment/software of different vendors, suppliers, etc.

For at least the reasons stated above, a migration from virtualized software infrastructure to containerized software infrastructure for the Telecom industry is expected to be a challenging, lengthy process. Accordingly, virtualized software infrastructure and containerized software infrastructure are likely to co-exist within the Telecom industry (and potentially other industries) during a transitionary period between the two technologies. For this reason, there is a need for flexible/adaptable computerized software development tools that facilitate efficient deployment for software systems in both virtualized and containerized environments.

As alluded to above, computerized CI/CD systems (sometimes referred to as CI/CD systems, or CI/CD chains) can significantly reduce the time required to develop, update, and deploy software systems.

However, existing CI/CD systems are ill-equipped to support an industry migration from virtualized software infrastructure to containerized software infrastructure. In part, this is because existing CI/CD systems tend to focus on a single technology: i.e., either virtualization or containerization. That is, existing CI/CD systems generally only facilitate natively containerized software solutions or purely virtualized software solutions—with few attempts to bridge the gap between the two. This can present a problem during a lengthy/iterative industry migration where virtualized and containerized infrastructure are expected to co-exist. Again, this problem can be associated with needing separate existing CI/CD systems to deploy a software system in both a virtualized and a containerized environment.

A related shortcoming of existing CI/CD systems that focus on containerized software solutions is that they generally assume container images (i.e., major building blocks of containerized software deployments) are built upstream. That is, these existing containerized software solution-focused CI/CD systems generally take container images as inputs. This can lead to inefficiencies (e.g., increased human labor, increased development costs, need for additional software tools/systems, etc.) in scenarios where a user (or team of users) wants to deploy a common software system in both a containerized and virtualized environment. For example, the extra upstream work required for generating container images does not advance/progress deployment in the virtualized environment. Relatedly, the upstream work required for generating the container images does not benefit from the automation advantages provided by the existing CI/CD systems. Moreover (and as alluded to above), generating container images can be especially complex for implementations involving legacy equipment/software (e.g., legacy Telecom equipment/software from the “Application Server era”) that was not designed from the ground up around containerization.

Against this backdrop, examples of the present technology provide computerized CI/CD systems that unify the CI/CD methodology for virtualized and containerized software environments. To realize this unification, CI/CD systems of the present technology are intelligently designed to leverage a common set of inputs (i.e., deployment descriptors and artifacts—to be described in greater detail below) that can facilitate automatic deployment of the software system in either a virtualized environment, a containerized environment, or both. Accordingly, CI/CD systems of the present technology provide a flexible, computerized software development tool that facilitates efficient, and automated deployment of software systems in both virtualized and containerized environments. Relatedly, and as will be described in greater detail below, CI/CD systems of the present technology also facilitate (and in some cases perform) automated generation of container images. Accordingly, CI/CD systems of the present technology can reduce inefficiencies associated with generating container images upstream from the CI/CD process—thereby improving efficiency for containerized software deployment. As alluded to above, by: (1) providing an improved computerized software development tool that facilitates efficient, and automated deployment of software systems in both virtualized and containerized environments; and (2) improving efficiency for containerized software deployment—CI/CD systems of the present technology may be better-equipped than existing CI/CD systems to support industry migrations from virtualized to containerized environments. This may include the expected/imminent migration for the Telecom industry. Relatedly, by providing an improved computerized CI/CD system, examples can improve functioning of software systems, and the computing devices on which the software systems are run. For example, CI/CD systems of the present technology can improve the functioning of Legacy telecom equipment by facilitating improved operation of the Legacy telecom equipment when running containerized workloads.

To achieve a unified virtualization/containerization solution, a CI/CD system of the present technology can leverage a versatile “deployment descriptor” that describes: (1) an inventory of instantiated components (i.e., instances of software components such as databases, application servers, services to be deployed in an application server, etc.) to be deployed in a software system; (2) relationships between the instantiated components within the software system; and (3) configuration parameters for the instantiated components. In some examples, the deployment descriptor for the software system may be provided to the CI/CD system by a user (or team of users) in the form of Layout and Settings files.

In various examples, the CI/CD system can also leverage “artifacts” that describe components being instantiated as the instantiated components (as used herein an artifact may refer to data or information, such as a computer file, that describes components being instantiated as the instantiated components). For example, an artifact may comprise a “component specification” file describing various aspects of a component in a formal language (e.g., a JSON-based language) such as the component's relationship with other components, potential configuration parameters for the component, etc. The artifact may also describe software packages (e.g., generated by a CI chain of the CI/CD system) supporting the component and deployment routines that allow the CI/CD system to perform various operations on instances of the component (e.g., configuration, installation, start-up, etc.). Artifacts may be “on-boarded” to a catalog of the CI/CD system by users in an iterative manner, or in conjunction with uploading the deployment descriptor. The deployment descriptor may refer back to on-boarded components when describing the instantiated components to be deployed in the software system.

As alluded to above, an advantage of the CI/CD system of the present technology is that the above-described inputs (i.e., deployment descriptors and artifacts) are leveraged for deploying the software system in a virtualized environment, a containerized environment, or both. This promotes improved efficiency (e.g., reduced human labor, reduced development costs, reduced need for additional software tools/systems, etc.) in scenarios where a user (or team of users) wants to deploy a common software system in both a containerized and virtualized environment. This is because—aside from typical inputs provided to the CI chain of the CI/CD system—the user (or team of users) may simply provide the above-described deployment descriptor and artifacts to a CI/CD system of the present technology. With these versatile inputs, the CI/CD system can then automatically deploy the software system in a virtualized environment, a containerized environment, or both

For example, in response to determining to deploy the software system in a containerized environment, the CI/CD system can: (1) use the artifacts and the deployment descriptor to compute containerization workflows for building container images for the software system; (2) provide the containerization workflows to a container image automation service that builds container images for the software system based on the containerization workflows; and (3) deploy the software system in the containerized environment using the built container images. In some examples, the CI/CD system may also determine containerization configuration parameters (i.e., configuration parameters for building container images) for building the container images for the software system and provide the determined containerization configuration parameters to the container image automation service. In various examples the container image automation service can be implemented as part of the CI/CD system—although in other examples the container image automation service can be an external service in communication with the CI/CD system. In certain examples, the container image automation service may publish the built container images to a container repository. In these examples, the containerized environment may pull the built container images from the container repository to run the software system in the containerized environment.

In contrast to the paragraph above, in response to determining to deploy the software system in a virtualized environment, the CI/CD system can (1) use the artifacts and the deployment descriptor to determine virtual computing resources for deploying the software system in the virtualized environment; and (2) in response to allocation of the determined virtual computing resources, compute and execute a virtualization workflow for deploying the software system in the virtualized environment using the allocated virtual computing resources. In certain examples, the CI/CD system may request the determined virtual computing resources from a virtual computing resource manager. In certain examples the virtual computing resource manager may be implemented as part of the CI/CD system—while in other examples the virtual computing resource manager may be an external service/manager in communication with the CI/CD system.

As will be described below, the CI/CD system can leverage various deployment technologies when deploying the software system in the containerized and virtual environments. As non-limiting examples, the CI/CD system may use Ansible®, Chef™, Salt™, etc.

Examples of the present technology will be described in greater detail on conjunction with the following FIGs.

FIG.1depicts an example CI/CD system100, in accordance with various examples of the present technology. As depicted, CI/CD system100comprises a CI chain100(a) and a CD chain100(b).

In some examples, CI chain100(a) can automatically build, integrate, and package source code published to CI/CD system100into components of a software system (examples of components may include databases, application servers, services to be deployed in an application server, etc.). As a simple example, source code for a component may be written and published in Java while a target operating system is RedHat Linux. CI chain100(a) can compile the Java source code, put binaries in a JAR file, and package the JAR file into a RedHat Package Manager (RPM) package that can be used to deliver/deploy the component on RedHat Linux. As will be described in greater detail below, an artifact associated with the component can reference this RPM package when describing the component. The artifact can also describe/define methods for deploying the component/RPM package.

As alluded to above, one or more software developers (e.g., of a software development team) working on the software system can publish the source code to CI/CD system100on a frequent/continuous basis (e.g., daily). CI chain100(a) can then automatically (and rapidly) build/integrate/package the published source code on a similarly frequent/continuous basis.

Once built/integrated/packaged, CI chain100(a) can test the components in a rapid manner—thereby identifying (and in some cases, remedying) bugs and other issues early and often. As depicted, in certain examples tested/validated components of the software system can be stored in software repository114.

CD chain100(b) can instantiate components of the software system tested/validated by CI chain100(a), and automatically deploy the instantiated components (i.e., instantiated components) in a virtualized software environment150, a containerized software environment160, or both.

As alluded to above, conventional computerized CI/CD systems tend to focus on a single technology: i.e., either virtualization or containerization. That is, existing CI/CD systems generally only facilitate natively containerized software solutions or purely virtualized software solutions—with few attempts to bridge the gap between the two. This can present a problem during migrations from virtualized to containerized software infrastructure where virtualized and containerized software infrastructure are expected to co-exist. Again, this problem may be associated with using separate existing CI/CD systems to deploy a software system in both a virtualized and a containerized environment.

To address this problem, examples of the present technology provide computerized CI/CD systems (e.g., CI/CD system100) that unify the CI/CD methodology for virtualized and containerized software environments. To achieve this unified virtualization/containerization solution, CI/CD system100leverages a versatile “deployment descriptor” and descriptive “artifacts”—which can be received as inputs to CD chain100(b).

The deployment descriptor may describe: (1) an inventory of instantiated components to be deployed in the software system; (2) relationships between the instantiated components within the software system; and (3) configuration parameters for the instantiated components. In some examples, the deployment descriptor for the software system may be provided to CI/CD system100by a user (or team of users) in the form of Layout and Settings files.

A Layout file can define instantiation of components and describe how the instantiated components connect to each other. For instance, if the software system includes a front-end web service and a back-end database, the front-end web service may be modeled by a first component and the back-end database may be modeled by a second component. The front-end web service component may contain information that explains the front-end web service component requires the back-end database component. Accordingly, a first Layout file may explain that an instance of the front-end web service component should be connected to an instance of the back-end database component. If this simple Layout is insufficient to handle all the traffic of the front-end web service, a second Layout file may explain that three instances of the front-end web service component are required, all of which should be connected to the instance of the back-end database component.

A Settings file can define the configuration parameters for each instantiated component. As a simplified example to illustrate the concept, the instantiated front-end web service component from above may need to be configured with an HTTP port. Relatedly, the instantiated back-end database component from above may need to be configured with a requisite amount of memory and disk. These parameters may first be defined in respective artifacts associated with the respective components (as described below). A Settings file for the first Layout described above (i.e., one instantiated front-end web service component and one instantiated back-end database component) may then hold the values of the HTTP port of the instantiated front-end web service component, and the requisite amount of memory and disk for the instantiated back-end database component. A Settings file for the second Layout described above (i.e., three instantiated front-end web service components and one instantiated back-end database component) may hold the three HTTP ports for the three instantiated front-end web service components, and the requisite amount of memory and disk for the instantiated back-end database component.

As depicted, CI/CD system100can also leverage “artifacts” that describe the components being instantiated as the instantiated components. As used herein, an artifact may refer to data or information, such as a computer file, that describes components being instantiated as the instantiated components. As alluded to above, the components described by the artifacts may be the components of the software system generated and tested/validated by CI chain100(a). In various examples, an artifact may comprise a “component specification” file describing various aspects of a component in a formal language (e.g., a JSON-based language) such as the component's relationship with other components, potential configuration parameters for the component, etc. The artifact may also describe software packages generated by CI chain100(a) supporting the component (e.g., an RPM package) and deployment routines that allow CI/CD system100to perform various operations on the instantiated components (e.g., configuration, installation, start-up, etc.). Artifacts may be “on-boarded” to a catalog of CI/CD system100by users in an iterative manner, or in conjunction with uploading the deployment descriptor. As alluded to above, the deployment descriptor may refer back to on-boarded components when describing the instantiated components to be deployed in the software system.

An advantage provided by CI/CD system100is that the above-described inputs (i.e., the deployment descriptor and artifacts) can be leveraged for deploying the software system in virtualized software environment150, containerized software environment160, or both. This promotes improved efficiency (e.g., reduced human labor, reduced development costs, reduced need for additional software tools/systems, etc.) in scenarios where user (or team of users) wants to deploy the software system in both a containerized and virtualized environment. This is because users may simply provide: (1) source code that CI chain100(a) builds/integrates/packages into components for the software system—which is a common/typical input for computerized CI/CD systems; and (2) the above-described deployment descriptor and artifacts. With these versatile inputs, CI/CD system100can then automatically deploy the software system in virtualized software environment150, containerized software environment160, or both.

Specific methodologies for deploying the software system in virtualized software environment150and containerized software environment160will be described in greater detail in conjunction withFIGS.2and3respectively.

FIG.2depicts an example flow diagram that may be used to implement automatic deployment of a software system in a virtualized environment, in accordance with various examples of the present technology. As depicted, CI/CD system100ofFIG.1may be used to implement such automatic deployment. Before describing the flow diagram in more detail, it should be understood that in various examples the disclosed steps may be performed in different orders.

At steps1aand1b, CI/CD system100can receive a deployment descriptor and artifacts associated with the software system.

As alluded to above, the deployment descriptor may describe: (1) an inventory of instantiated components to be deployed in the software system; (2) relationships between the instantiated components within the software system; and (3) configuration parameters for the instantiated components. In some examples, the deployment descriptor for the software system may be provided to CI/CD system100(e.g., by a user or team of users) in the form of Layout and Settings files.

As alluded to above, the “artifacts” may describe the components being instantiated as the instantiated components. As alluded to above, such components may be components of the software system generated and tested/validated by a CI chain of CI/CD system100(e.g., CI chain100(a)). In various examples, an artifact may comprise a “component specification” file describing various aspects of a component in a formal language (e.g., a JSON-based language) such as the component's relationship with other components, potential configuration parameters for the component, etc. The artifact may also describe software packages generated by the CI chain of CI/CD system supporting the component (e.g., an RPM package) and deployment routines that allow CI/CD system100to perform various operations on the instantiated components (e.g., configuration, installation, start-up, etc.). Artifacts may be “on-boarded” to a catalog of CI/CD system100by users in an iterative manner, or in conjunction with uploading the deployment descriptor. The deployment descriptor may refer back to on-boarded components when describing the instantiated components to be deployed in the software system.

At step2, CI/CD system100can use the deployment descriptor and artifacts to determine virtual computing resources (e.g., virtual machines) for deploying/hosting the software system in a virtualized environment. In some examples, after determining the virtual computing resources for deploying/hosting the software system in the virtualized environment, CI/CD system can request the virtual computing resources from a virtual computing resource manager220. In certain examples, the virtual computing resource manager220may be implemented as part of CI/CD system100. In other examples, virtual computing resource manager220may be implemented separately from, but in communicative connection with, CI/CD system100. In some examples, CI/CD system100may include VNF SW settings with a request for determined virtual computing resources. Here it should be understood that steps1and2may occur several days or weeks before deployment of the software system which starts at step3. It can be a challenge for CI/CD system100to hold contextual information related to the software system for this time duration. Accordingly, the VNF SW settings can hold this contextual information related to the software system. The VNF SW settings may be generated at step2by CI/CD system100. CI/CD system100may later consume the VNF SW settings/contextual information at step4.

At step3, the virtual computing resources for deploying/hosting the software system in the virtualized environment are allocated. As alluded to above, these virtual computing resources may be allocated by virtual computing resource manager220. Allocating the virtual computing resources may include creating/generating virtual machines. Names, IP addresses, and network connections for the virtual machines may be generated by virtual computing resource manager220at step3.

At step4, the allocated virtual computing resources may be triggered back to CI/CD system100. In this way, CI/CD system100obtains information related to the allocated virtual computing resources (e.g., what networks the allocated virtual computing resources/virtual machines are connected to, names of the allocated virtual computing resources/virtual machines, IP addresses of the allocated virtual computing resources/virtual machines, etc.) In some examples, VNF SW settings may be included with the allocated virtual computing resources. As alluded to above, the VNF SW settings may hold contextual information related to the software system that can be used/consumed by CI/CD system100to assist with performance of step4.

At step5, using the deployment descriptor and artifacts, CI/CD system100computes and executes a virtualization workflow (e.g., an Ansible virtualization playbook) for deploying the software system in the virtualized environment using the allocated virtual computing resources. The virtualization workflow may define a set of instructions for instantiating components, and deploying instantiated components for the software system within the virtualized environment. For example, the virtualization workflow may detail an appropriate sequence of deployment routines to be run for instantiating appropriate components on appropriate virtual machines.

In various examples, CI/CD system100can also use the deployment descriptor and artifacts to determine virtualization configuration parameters (i.e., configuration parameters for deploying instantiated components using virtual machines) for deploying the software system in the virtualized environment using the allocated virtual computing resources. CI/CD system100can use the determined virtualization configuration parameters (in addition to the virtualization workflow) for instantiating components, and deploying instantiated components for the software system within the virtualized environment.

In some examples, CI/CD system100can natively integrate with various virtualized infrastructure types such as OpenStack, VMWare, ETSI NFV, Amazon Web Services, etc. Relatedly, various deployment technologies may be leveraged to deploy the software system in the virtualized software environment (e.g., Ansible®, Chef™, Salt™, etc.).

FIG.3depicts an example flow diagram that may be used to implement automatic deployment of a software system in a containerized environment, in accordance with various examples of the present technology. CI/CD system100ofFIG.1may be used to implement such automatic deployment. Before describing the flow diagram in more detail, it should be understood that in various examples the disclosed steps may be performed in different orders.

At steps1aand1b, CI/CD system100can receive the same deployment descriptor and artifacts associated with the software system as described in conjunction withFIG.2for automatic deployment of the software system in the virtualized environment.

As alluded to above, an advantage provided by CI/CD system100is that the above-described inputs (i.e., the deployment descriptor and artifacts) can be leveraged for deploying the software system in a virtualized software environment, a containerized software environment (e.g., containerized software environment160), or both. This promotes improved efficiency (e.g., reduced human labor, reduced development costs, reduced need for additional software tools/systems, etc.) in scenarios where a user (or team of users) wants to deploy the software system in both a containerized and virtualized environment. This is because the user (or team of users) may simply provide: (1) source code published to CI/CD system100which CI/CD system100uses to build/integrate/package components of the software system; and (2) the above-described deployment descriptor and artifacts. With these versatile inputs, CI/CD system100can then automatically deploy the software system in a virtualized software environment, containerized software environment160, or both.

At step2, CI/CD system100can use the artifacts and the deployment descriptor to compute a set of containerization workflows (e.g., a set of Ansible containerization playbooks) for building container images for the software system. Here, each containerization workflow may be used to build a separate container image. Relatedly, each containerization workflow/container image may correspond to a separate workload in the containerized environment. Accordingly, a containerization workflow may define a set of instructions for instantiating components of a specific workload of the software system, and deploying the instantiated components of the specific workload within containerized environment160. For example, a containerization workflow can detail installation deployment routines for construction of a container image, configuration and startup routines for bootstrapping instantiated components within the container image, etc.

In certain examples, CI/CD system100may also use the artifacts and the deployment descriptor to determine containerization configuration parameters (e.g., Ansible inventory) for building the container images for the software system.

In various examples, CI/CD system100can provide the containerization workflows and containerization configuration parameters to a container image automation service320. In certain examples, container image automation service320may be implemented as part of CI/CD system100. In other examples, container image automation service320may be implemented separately from, but in communicative connection with, CI/CD system100.

At step3, container image automation service320builds container images for the software system based on the containerization workflows and the containerization configuration parameters. As depicted, container image automation service320can publish the built container images to a container image repository340—which can later be accessed by containerized software environment160to deploy and run the software system in containerized software environment160.

At step4, CI/CD system100can deploy/launch the software system in containerized environment160using the built container images. As alluded to above, containerized software environment160can pull the built containerized images from container repository340and run them as part of this deployment process (see e.g., step5ofFIG.3).

The process ofFIG.3can be implemented with various containerization platforms/orchestration tools (e.g., Kubernetes, Docker Swarm, Apache Mesos, etc.). Relatedly, various deployment technologies may be leveraged to deploy the software system in the virtualized software environment (e.g., Ansible®, Chef™, Salt™, etc.).

Before describingFIG.4, it should again be understood that CI/CD system100provides an added advantage over many existing CI/CD systems that take container images as inputs. As alluded to above, relying on upstream container image generation can lead to inefficiencies (e.g., increased human labor, increased development costs, need for additional software tools/systems, etc.) in scenarios where a user (or team of users) wants to deploy a common software system in both a containerized and virtualized environment. For example, the extra upstream work required for generating container images does not advance/progress deployment in the virtualized environment. Relatedly, the upstream work required for generating the container images does not benefit from the automation advantages provided by the existing CI/CD systems. Accordingly, by facilitating (and in some cases performing) automated generation of container images, CI/CD system100can reduce inefficiencies associated with generating container images upstream from the CI/CD process—thereby further improving efficiency for containerized software deployment. Moreover (and as described above), by facilitating automatic deployment a software system in a virtualized environment and a containerized environment using a common set of inputs (i.e., a deployment descriptor and artifacts), CI/CD system100provides even further efficiency improvements by “filling two needs with one deed.”

Here, CI/CD system100can automate container image generation because the artifacts and deployment descriptor of the present technology are intelligently configured/designed to contain the information required for such automation.

FIG.4illustrates an example computing component400that may be used to deploy a software system in a virtualized software environment, a containerized software environment, or both, in accordance with various examples of the present technology. In various examples, computing component400may be used to implement a CI/CD system of the present technology—such as CI/CD system100.

Referring now toFIG.4, computing component400may be, for example, a server computer, a controller, or any other similar computing component capable of processing data. In the example implementation ofFIG.4, the computing component400includes a hardware processor402, and machine-readable storage medium for404.

Hardware processor402may be one or more central processing units (CPUs), semiconductor-based microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium404. Hardware processor402may fetch, decode, and execute instructions, such as instructions406-410, to control processes or operations for burst preloading for available bandwidth estimation. As an alternative or in addition to retrieving and executing instructions, hardware processor402may include one or more electronic circuits that include electronic components for performing the functionality of one or more instructions, such as a field programmable gate array (FPGA), application specific integrated circuit (ASIC), or other electronic circuits.

A machine-readable storage medium, such as machine-readable storage medium404, may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, machine-readable storage medium404may be, for example, Random Access Memory (RAM), non-volatile RAM (NVRAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, and the like. In some examples, machine-readable storage medium404may be a non-transitory storage medium, where the term “non-transitory” does not encompass transitory propagating signals. As described in detail below, machine-readable storage medium404may be encoded with executable instructions, for example, instructions406-410. Before describing instructions406-410in more detail, it should be understood that in various examples instructions406-410may be performed in various orders.

Hardware processor402may execute instruction406to receive a deployment descriptor describing an inventory of instantiated components to be deployed in a software system, relationships between the instantiated components within the software system, and configuration parameters for the instantiated components.

Hardware processor402may execute instruction408to receive artifacts describing components instantiated as the instantiated components.

In various examples, hardware processor402may also build and package the components being instantiated as the instantiated components. As alluded to above, building and packaging the components may be associated with a CI chain/stage that occurs prior to instantiation and deployment of components.

In various examples, the artifacts received at instruction408may be received before the deployment descriptor at instruction406. In other words, hardware processor402may execute instruction408before instruction406.

Hardware processor402may execute instruction410to: (a) in response to determining to deploy the software system in the virtualized environment, use the deployment descriptor and the artifacts to deploy the software system in the virtualized environment; and (b) in response to determining to deploy the software system in the containerized environment, using the deployment descriptor and the artifacts to deploy the software system in the containerized environment. In some examples, hardware processor402can make these determinations in response to user input—although this need not be the case in other examples,

In some examples, deploying the software system in the virtualized environment may comprise: (i) using the deployment descriptor and the artifacts to determine virtual computing resources for deploying the software system in the virtualized environment; and (ii) in response to allocation of the determined virtual computing resources, computing and executing a virtualization workflow for deploying the software system in the virtualized environment using the allocated virtual computing resources. In certain examples, hardware processor402may request the determined virtual computing resources from a virtual computing resource manager.

In some examples, deploying the software system in the containerized environment may comprise: (i) using the deployment descriptor and the artifacts to compute containerization workflows for building container images for the software system; (ii) providing the containerization workflows to a container image automation service, wherein the container image automation service builds container images for the software system based on the containerization workflows; and (iii) deploying the software system in the containerized environment using the built container images. In other examples, deploying the software system in the containerized environment may comprise: (i) using the deployment descriptor and artifacts to compute containerization workflows for building container images for the software system; (ii) building container images for the software system based on the containerization workflows; and (iii) deploying the software system in the containerized environment using the built container images.

In various examples, hardware processor402and/or the container automation service may publish the built container images to a container image repository. In these examples, the containerized environment may pull the built container images from the container image repository to run the software system in the containerized environment.

In some examples, deploying the software system in the containerized environment may further comprise: (i) using the deployment descriptor and the artifacts to determine containerization configuration parameters for building the container images for the software system; and (ii) providing the determined containerization configuration parameters to the container image automation service, wherein the container image automation service builds the container images for the software system based on the containerization workflows and the determined containerization configuration parameters. In related examples, hardware processor402may use the containerization workflows and the determined containerization configuration parameters to build the container images.

In some examples, the containerization workflows and the virtualization workflow may be computed and executed using at least one of the following deployment technologies: (a) Ansible®; (b) Chef™; Salt™.

FIG.5depicts a block diagram of an example computer system500in which various of the examples described herein may be implemented. For example, computing system500may be used to implement a CI/CD system of the present technology—such as CI/CD system100. Relatedly, computing system500may be used to implement computing component400ofFIG.4

The computer system500includes a bus502or other communication mechanism for communicating information, one or more hardware processors504coupled with bus502for processing information. Hardware processor(s)504may be, for example, one or more general purpose microprocessors.

The computer system500further includes a read only memory (ROM)508or other static storage device coupled to bus502for storing static information and instructions for processor504. A storage device510, such as a magnetic disk, optical disk, or USB thumb drive (Flash drive), etc., is provided and coupled to bus502for storing information and instructions.

The computer system500may be coupled via bus502to a display512, such as a liquid crystal display (LCD) (or touch screen), for displaying information to a computer user. An input device514, including alphanumeric and other keys, is coupled to bus502for communicating information and command selections to processor504. Another type of user input device is cursor control516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor504and for controlling cursor movement on display512. In some examples, the same direction information and command selections as cursor control may be implemented via receiving touches on a touch screen without a cursor.

The computer system500may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system500to be a special-purpose machine. According to one example, the techniques herein are performed by computer system500in response to processor(s)504executing one or more sequences of one or more instructions contained in main memory506. Such instructions may be read into main memory506from another storage medium, such as storage device510. Execution of the sequences of instructions contained in main memory506causes processor(s)504to perform the process steps described herein. In alternative examples, hard-wired circuitry may be used in place of or in combination with software instructions.

The computer system500also includes a communication interface518coupled to bus502. Communication interface518provides a two-way data communication coupling to one or more network links that are connected to one or more local networks. For example, communication interface518may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface518may be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component to communicated with a WAN). Wireless links may also be implemented. In any such implementation, communication interface518sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

The computer system500can send messages and receive data, including program code, through the network(s), network link and communication interface518. In the Internet example, a server might transmit a requested code for an application program through the Internet, the ISP, the local network and the communication interface518.

It should be noted that the terms “optimize,” “optimal” and the like as used herein can be used to mean making or achieving performance as effective or perfect as possible. However, as one of ordinary skill in the art reading this document will recognize, perfection cannot always be achieved. Accordingly, these terms can also encompass making or achieving performance as good or effective as possible or practical under the given circumstances, or making or achieving performance better than that which can be achieved with other settings or parameters.