Patent ID: 12248780

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Implementations of the present disclosure are directed to continuous integration (CI)/continuous delivery (CD) pipelines. More particularly, implementations of the present disclosure provide a CI/CD platform that enables developers, such as low-code/no-code (LCNC) developers, to configure CI/CD jobs in a simple and intuitive manner for automated builds of applications in response to change commits.

In some implementations, actions include receiving, through a set of user interfaces (UIs), user input including job configuration information and deployment information for an application, providing a CI/CD job for the application with a CI/CD service using the job configuration information and the deployment information, and triggering, in response to a commit of changes to the application in a repository, automated build of the application, and in response, automatically: generating a development descriptor file at least partially based on the user input, providing an archive file including the development descriptor file, and processing, by the CI/CD job executed by the CI/CD service, the archive file to deploy the application within the target environment.

As used herein, the terms low-code and no-code generally refer to software development platforms and/or tools that are targeted at users with little or no development experience (e.g., referred to as citizen developers, or LCNC developers). Another target of such platforms and/or tools can include more experienced developers having shorter timeframes for development (e.g., LCNC enabling developers to develop more quickly). Here, low-code can refer to development requiring some level of coding experience, while no-code can refer to development with no coding experience. In the context of implementations of the present disclosure, LCNC CI/CD developers generally refers to developers of applications. While the present disclosure references low-code developers and/or no-code developers, collectively LCNC developers or citizen developers, it is appreciated that implementations of the present disclosure can be realized for the benefit of more sophisticated developers.

To provide further context for implementations of the present disclosure, and as introduced above, lifecycles of applications can include integration and delivery of changes (e.g., updates, patches). In some examples, integration can be described as integrating changes to an application and delivery can be described as delivering (or deploying) the changes to the application (e.g., while executing in a production (runtime) environment). Continuous integration (CI) and continuous delivery (CD) can be provided through a CI/CD pipeline. CI can be described as a development process, in which developers integrate their respective contributions (e.g., changes to application code) frequently into a single main line, and, before each integration, the changes are verified through builds and automated testing. CD can be described as expanding on CI in that any changes that successfully pass testing are automatically deployed to the production environment.

Traditional CI/CD pipelines, however, can require administrators and developers to deal with multiple, disparate systems including, for example, development environments, configuration management, source control, and build servers, each of which requires in-depth and specific knowledge on various aspects. Further, traditional CI/CD pipelines can require developers to drill down to the source code level to perform highly technical tasks, such as integration and testing. Performing such tasks, however, is time- and resource-intensive and typically requires highly skilled and experienced developers in multiple disparate technologies. Further, numerous technical resources need to be provisioned, deployed, and consumed for design-time integration and runtime delivery of changes to applications executing in production environments.

In view of the above context, implementations of the present disclosure provide a CI/CD platform that is hosted within a cloud platform that also hosts and executes applications, for which CI/CD functionality is to be provided. In some implementations, the CI/CD platform includes a user-facing frontend and a backend engine. In some examples, the frontend is built into an application studio and provides intuitive and user-friendly user interfaces (UIs) for CI/CD job creation and configuration. In some examples, an application studio can include software or a suite of software that supports development and deployment of applications as well as application lifecycles. In some examples, the backend engine executes the CI/CD pipelines. For example, the backend engine orchestrates and consumes various backend services to provide CI/CD functionality. As described in further detail herein, the CI/CD platform of the present disclosure consolidates the functions of different CI/CD systems into a unified and easy-to-use environment and encapsulates the low-level coding facing tasks into high-level human facing tasks. In this manner, LCNC developers (citizen developers) are relieved from the difficult low-level technical tasks of integration and delivery, empowering LCNC developers to easily perform CI/CD tasks.

Implementations of the present disclosure are described with reference to various entities, at least some of which are provided by SAP SE of Walldorf, Germany. An example entity includes the Business Technology Platform (BTP), which can be described as a platform that brings together data and analytics, artificial intelligence, application development, automation, and integration in a unified environment. Another example entity includes the Cloud Application Programming Model (CAP), which can be described as a framework of languages, libraries, and tools for building enterprise-grade services and applications. Another example entity includes Core Data Services (CDS), which can be described as an infrastructure within CAP that can be used by developers to create an underlying (persistent) data model, which the applications expose to UI clients. In some examples, CDS includes a command line client and development toolkit that is referred to as CDS-DK (or cds-dk). Another example entity includes the Business Application Studio (BAS), which can be described as a cloud-based development tool for building applications.

Another example entity is a multi-target application (MTA), which includes multiple modules (software modules) that share a common lifecycle for development and deployment. In some examples, the modules can be developed using different technologies and languages and can be deployed to different target environments. However, in the context of a MTA, the modules serve respective aspects of a particular purpose for users of the application. As such, a MTA can include a group of modules packaged into a MTA archive along with a MTA deployment descriptor. MTAs can be distributed across multiple containers and target platforms. The MTA approach enables adoption of a common life-cycle process (from development to deployment) for all application artifacts to be deployed to the target platform(s).

Another example entity includes the Cloud MTA Build Tool (MBT), which can be described as a standalone command-line tool that builds a deployment-ready MTA using a respective archive file (e.g., .mtar file) from the artifacts of a MTA project. In some examples, the archive file is built using a development descriptor (mta.yaml file) of the application, which is discussed in further detail herein. In some examples, the development descriptor includes design-time module types that are converted into deployment time module types, when the application is deployed. In some examples, the archive file includes one or more MTA modules and configuration files (e.g., a deployment manifest, a deployment descriptor). Another example entity includes Jenkins, which can be described as a shared library for CI/CD pipelines.

While reference is made herein to the above-discussed entities for purposes of non-limiting illustration, it is contemplated that implementations of the present disclosure can be realized using any appropriate entities.

FIG.1depicts an example architecture100in accordance with implementations of the present disclosure. In the depicted example, the example architecture100includes a client device102, a network106, and a server system104. The server system104includes one or more server devices and databases108(e.g., processors, memory). In the depicted example, a user112interacts with the client device102.

In some examples, the client device102can communicate with the server system104over the network106. In some examples, the client device102includes any appropriate type of computing device such as a desktop computer, a laptop computer, a handheld computer, a tablet computer, a personal digital assistant (PDA), a cellular telephone, a network appliance, a camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, an email device, a game console, or an appropriate combination of any two or more of these devices or other data processing devices. In some implementations, the network106can include a large computer network, such as a local area network (LAN), a wide area network (WAN), the Internet, a cellular network, a telephone network (e.g., PSTN) or an appropriate combination thereof connecting any number of communication devices, mobile computing devices, fixed computing devices and server systems.

In some implementations, the server system104includes at least one server and at least one data store. In the example ofFIG.1, the server system104is intended to represent various forms of servers including, but not limited to a web server, an application server, a proxy server, a network server, and/or a server pool. In general, server systems accept requests for application services and provides such services to any number of client devices (e.g., the client device102over the network106). In some examples, the server system104can provision a cloud platform that hosts one or more cloud-based applications (e.g., MTAs).

In accordance with implementations of the present disclosure, the server system104can host a CI/CD platform. As described in further detail herein, the CI/CD platform is hosted within a cloud platform that hosts and executes applications (e.g., MTAs), for which CI/CD functionality is to be provided. In some implementations, the CI/CD platform includes a user-facing frontend and a backend engine. In some examples, the frontend is built into an application studio and provides intuitive and user-friendly UIs for CI/CD pipelines. In some examples, the backend engine executes the CI/CD pipelines. For example, the backend engine orchestrates and consumes various backend services to provide CI/CD functionality. Example backend services include, without limitation, source control, application build, application transport management, application launchpad, and the like.

FIG.2depicts an example architecture200in accordance with implementations of the present disclosure. The example architecture200includes an application development platform202, a CI/CD service204, a booster206, and a repository208. In some examples, the repository208can be provided as a so-called git repository (e.g., a central github). In the example ofFIG.2, a developer210interacts with the application development platform202(e.g., through the client device102ofFIG.1). An example application development platform202includes, without limitation, the BAS.

In the example ofFIG.2, the application development platform202includes a CI/CD code extension module220, a CI/CD guided development module222, a CI/CD generator module224, and a configuration store226, and the booster206includes a CI/CD subscription module228. In some examples, the CI/CD code extension includes a CI/CD panel sub-module230, a build notification sub-module232, and a CI/CD settings sub-module234. In some examples, the CI/CD guided development module222includes a project sharing sub-module240, a job configuration sub-module242, and a webhook sub-module244. In some examples, the CI/CD generator module224includes a job name sub-module250, a repository credentials sub-module252, a test sub-module254, and a release sub-module256.

In some examples, the CI/CD code extension module220is an extension component to an integrated development environment (IDE) (e.g., to BAS Web IDE). In some examples, the CI/CD panel sub-module230enables a panel of the IDE to render CI/CD content that can support multiple projects. Each project can support multiple CI/CD jobs and, for each CI/CD job, the developer210can create, edit, and delete the job, manually trigger a build for the job and go to the CI/CD service204(e.g., a cockpit provided by the service) to monitor the progress of a particular build. The build notification sub-module232supports a timer that can periodically compare the latest status and previous status of each build, and, if the status is changed, a notification message will be displayed to notify the developer210of the change. The CI/CD settings sub-module234enables the developer210to turn on/off settings, such as the build notification.

In accordance with implementations of the present disclosure, the CI/CD guided development module222guides the developer210through application development and configuration of CI/CD jobs. For example, the CI/CD guided development module222provides a guided wizard using a set of UIs. In some examples, the developer210can navigate the guided wizard through the set of UIs to configure CI/CD functionality for an application. In some examples, the set of UIs enable the creation, sharing, and configuration of CI/CD jobs. In some examples, a CI/CD job executes tasks to build and deploy an application to a runtime environment (e.g., a Cloud Foundry environment). For example, the CI/CD job can be executed by the CI/CD service204and informs the CI/CD service204what is to be executed and when.

In some implementations, a guided development UI enables the developer210to create a CI/CD job for an application. The guided development UI includes selections for sharing the to-be-created CI/CD job (e.g., to a repository, such as a git repository), job configuration, and build automation. For example, the guided development UI can include a share interface, a job configuration interface, and a build automation interface.

In some examples, in response to the developer210selecting the share interface UI, a repository uniform resource locator (URL) text box is displayed, in which the developer210can enter the URL for the project within the repository208. For example, the project sharing sub-module240ingests the URL input by the developer210and links the CI/CD job to the project (e.g., application code) within the repository208. In some examples, in response to the developer210selecting the job configuration interface, a set of job configuration UIs is provided. In some examples, the set of job configuration UIs includes a job name UI, a repository credentials UI, and a deployment UI. The job name UI enables the developer210to input a job name that is to be assigned to the CI/CD job, the repository credentials UI enables the developer to input credentials (e.g., username, password) for accessing the project within the repository208, and the deployment UI enables the developer to input deployment information.

The deployment information indicates a space within a cloud-based environment (e.g., a Cloud Foundry space), where the application is to be deployed to and can include, without limitation, an application programming interface (API) endpoint, an organization name, a space name, and credentials (e.g., username, password). In some examples, job configuration information is ingested by the job configuration sub-module242and the deployment information is ingested by the webhook sub-module244. In some examples, a CI/CD job is created using the job configuration information. Example job configuration information can include, without limitation, job name, description, repository (e.g., Github repository), repository credentials, branch, pipeline, retention parameters, and the like. In some examples, the deployment information is used to create a webhook between the repository208and the CI/CD service204. A webhook can be described as a HTTP-based callback function for event-driven communication between APIs and, in the context of the present disclosure, enables automated CI/CD application builds. For example, and as described in further detail herein, a webhook push event is sent to the CI/CD service204to trigger a build of the application in response to changes to the application code being committed to the repository208.

In some implementations, the CI/CD generator224generates a manifest file (e.g., a config.yml file) for each CI/CD project. In some examples, the manifest file is populated by the input of the developer210to the guided wizard as well as input provided to the visual editor. In some examples, the manifest file contains all information required to execute the CI/CD functionality for the respective application, identifies the backend services used to execute the CI/CD functionality (e.g., the CI/CD service204) as well as dependencies, and details the process for build and deployment. In some examples, the CI/CD generator224generates the manifest file from a shell file that includes multiple placeholders that are then populated with information input by the developer to the guided wizard.

In some examples, the manifest file can be described as a development descriptor that defines elements and dependencies of the application, for which the CI/CD functionality is provided (e.g., the application that is stored in the repository208). In some examples, the application defined in the manifest file is a MTA, discussed above. Unlike traditional manifest files, the manifest file of the present disclosure enables the application project to be correctly built in multiple, disparate environments including, for example, local preview, local build, and Jenkins build, without the need for manual intervention by developers. That is, traditional manifest files can only build the application project in a predefined environment. If the environment does not meet requirements, it will fail, and a developer needs to install the corresponding dependencies based on the error(s).

FIGS.3A-3Fcollectively depict example content300of a manifest file (development descriptor) in accordance with implementations of the present disclosure.

The development descriptor (mta.yaml file) of the present disclosure is generated at design time and a deployment descriptor (mtad.yaml file) is created automatically when the application project is built. The deployment descriptor is automatically packaged into the archive file and deployed to the cloud. Developers do not need to directly interact with the deployment descriptor as it is part of the deployment process.

In some examples, the CI/CD service204can be described as a service that enables configuration and execution of predefined CI/CD pipelines. An example CI/CD service is provided on the BTP. In some examples, the CI/CD service204functions as an automation tool that retrieves the latest state of the repository208, builds the project, and deploys the project to a cloud-based environment (e.g., Cloud Foundry environment).

In some examples, the booster206provides a set of guided interactive steps that enable the developer210to select, configure, and consume services (e.g., on the BTP) to achieve a specific technical goal. In some examples, the booster206setups various CI/CD modules (e.g., provisioning service instances, creating and configuring user account and creating and assigning role collections, etc.).

FIG.4depicts an example signal flow diagram400in accordance with implementations of the present disclosure. In the example ofFIG.4, the example signal flow diagram400depicts example interactions between the developer210, the application development platform202, the repository208, and the CI/CD service204ofFIG.2.

The developer210shares (402) a project to the repository208. For example, the project is a development project for a MTA that is stored in the repository for subsequent deployment to a target environment (e.g., cloud-based environment). In some examples, the repository208stores (404) the project and provides (406) information (e.g., endpoint) to the developer210. The developer210creates (408) a CI/CD job for the project within the application development platform202. In response, the application development platform202creates (410) the CI/CD job with the CI/CD service204, which registers (412) the CI/CD job. For example, the CI/CD job is created using the job configuration information and the deployment information input by the developer210through the set of job configuration UIs. Confirmations of creation of the CI/CD job are sent (414,416). The developer210configures (418) a webhook with the repository208for automated build of the application. The repository208registers (420) the webhook for the application and provides (422) confirmation to the developer210. With the webhook in place, any changes to the application code committed to the repository208will trigger automated build of the application through the CI/CD pipeline.

The developer pushes (424) a committal of changes in the application code to the repository208. In response, the repository208triggers a webhook event that is communicated (426) to the CI/CD service204to trigger automated build (428) of the application (i.e., based on the changed application code), which can be communicated (430,432) to the developer210. In some examples, during the automated build (428), the application development platform202can periodically poll the CI/CD service204for a status.

FIG.5depicts an example process500that can be executed in accordance with implementations of the present disclosure. In some examples, the example process500is provided using one or more computer-executable programs executed by one or more computing devices.

Build of the application is triggered (502). For example, and as described herein, the developer210can push committal of changes in application code to the repository208. In response, the repository208triggers a webhook event that is communicated to the CI/CD service204to trigger an automated build of the application (i.e., based on the changed application code). It is determined whether CDS is available (504). For example, and as discussed herein, the deployment descriptor (mta.yaml file) is used to ensure that the application project can be correctly built in different environments. However, particular development toolkits (e.g., @sap/cds-dk) are not installed by default in all development environments. Consequently, a check is performed during the before-all stage to automatically install the development toolkit if it is missing.

If CDS is available, an archive file for the application is built (506). For example, and as described herein, a development descriptor (e.g., mta.yaml file) is automatically generated based on input previously received through the UIs and is included in the archive file that is built. If CDS is not available, extra dependencies are installed (508), dependencies are added into the path (510), and the archive file for the application is built (506). For example, and as noted above, the development descriptor (mta.yaml file) ensures that the current project can be correctly built in different environments. Therefore, during the before-all stage, a check is performed to automatically install any missing dependencies. Adding a dependency to path allows for using shorter command lines to execute the corresponding commands. For example, cds build-production can be called instead of using /home/user/projects/test/node_modules/.bin/cds build-production.

The archive file is deployed to the target environment (512). For example, and as described herein, the archive file is used in the target environment to build the application. In some examples, the MBT builds the deployment-ready MTA using the respective archive file (e.g., .mtar file) from the artifacts of the MTA project.

Referring now toFIG.6, a schematic diagram of an example computing system600is provided. The system600can be used for the operations described in association with the implementations described herein. For example, the system600may be included in any or all of the server components discussed herein. The system600includes a processor610, a memory620, a storage device630, and an input/output device640. The components610,620,630,640are interconnected using a system bus650. The processor610is capable of processing instructions for execution within the system600. In some implementations, the processor610is a single-threaded processor. In some implementations, the processor610is a multi-threaded processor. The processor610is capable of processing instructions stored in the memory620or on the storage device630to display graphical information for a user interface on the input/output device640.

The memory620stores information within the system600. In some implementations, the memory620is a computer-readable medium. In some implementations, the memory620is a volatile memory unit. In some implementations, the memory620is a non-volatile memory unit. The storage device630is capable of providing mass storage for the system600. In some implementations, the storage device630is a computer-readable medium. In some implementations, the storage device630may be a floppy disk device, a hard disk device, an optical disk device, or a tape device. The input/output device640provides input/output operations for the system600. In some implementations, the input/output device640includes a keyboard and/or pointing device. In some implementations, the input/output device640includes a display unit for displaying graphical user interfaces.

The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier (e.g., in a machine-readable storage device, for execution by a programmable processor), and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. Elements of a computer can include a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer can also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).

To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.

The features can be implemented in a computer system that includes a backend component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, for example, a LAN, a WAN, and the computers and networks forming the Internet.

The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.

A number of implementations of the present disclosure have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the present disclosure. Accordingly, other implementations are within the scope of the following claims.