WO2002037273A2 - Code deployment systems and methods - Google Patents

Abstract

Methods and systems for deploying software code, for example between customers and web hosting infrastructures are provided. A customer can point a browser to a predetermined address to invoke a GUI that provides access to various deployment functionality. For example, the customer can upload packages to a staging host, install uploaded packages on the staging host, test code which has been installed on the staging host and selected tested code for promotion to a production host. The described techniques also provide for a handoff to web site hosting personnel to complete the promotion of the software code onto the production host.

Description

CODE DEPLOYMENT SYSTEMS AND METHODS

BACKGROUND

The present invention relates generally to systems and methods for deploying software code into production in a controlled, uniform and automated manner. More particularly, the present invention relates to systems and methods for enabling customers to transition code which they (or others) have developed for their web site from testing into production, e.g., in situations where their web site is being hosted by a third party.

In the 1990's, the global, distributed computer network known as the Internet became a powerful tool for business. Whole new categories of business, referred to by the umbrella term of "e-commerce", were created to take advantage of the potential efficiencies provided by rapid, global information exchange and these new businesses quickly captured the attention of both the public and private industry. Among other things, the Internet acts as a transport mechanism for the World Wide Web, which can be described as a global, interconnected system of navigational links between collections of data. The World Wide Web is comprised of a very large number of web sites, each of which is a smaller group of linked data collections, e.g., web documents, that is accessible via the interconnected computer network.

In order to provide the interconnectivity which is ubiquitous to the Internet, standard protocols were adopted for its various aspects. For example, the Transfer Control Protocol/Internet Protocol (TCP/IP) was adopted as the lowest level data transfer protocol by which computers exchange data over the Internet. HyperText Markup Language (HTML) provides a set of coding conventions which define how to present and link documents stored in the documents that make up web site data collections. Similarly, HyperText Transfer Protocol (HTTP) has been adopted as the client-server protocol by which documents are requested and transmitted over the World Wide Web. Web object addresses have been standardized by uniform resource locators (URLs) which uniquely identify a location of an object for retrieval via the World Wide Web. At their inception, web sites employed in e-commerce were typically designed, constructed, and operated by the same organization, often by the same people. Such e- commerce companies therefore had complete control and understanding of all of the software used in running their web site. This software included both high level graphical user interface and linking code, as well the business logic code (i.e., code performing business-related functions such as a shopping basket, order management, chat, searching, etc.) which underlies the display and document linking functionality of the web site. Thus the site operators were well positioned to adapt the existing code and to design and implement additional code as desired to change the appearance and/or functionality of the web site.

As the e-commerce industry experienced explosive growth, the level of effort required to operate and maintain more complex and sophisticated web sites increased in tandem. This, in turn, led to the development of web site operation and hosting services, where an e-commerce company out-sources the operational aspects of running their web site to another company, although the creation of the underlying business logic code typically remained with the e-commerce company itself. While this outsourcing of web site operation permitted e-commerce companies to focus their resources on their core business, it also created a situation where neither the writers of the web site code nor the writers of the web site infrastructure and operations software can independently introduce updates to either the high level graphical user interface and linking code or the business logic code associated with the web site.

Of course, it is possible for the customer (e.g., the e-commerce company) and the web site operations and hosting company to arrange some sort of ad hoc updating protocol whereby web site code updates are transferred from the customer to the web site hosting and operation service company, e.g., by sending the web site hosting and operation company a disk with the updates stored thereon for posting to that company's web server.

However, such an ad hoc updating arrangement suffers from several drawbacks. First, it does not provide the customer with a robust or efficient mechanism for testing and transferring code from a staging environment to its live web site. Second, if the web site operations and hosting company has scaled its business to hundreds or thousands of customers, using different, highly manual processes to update the code associated with different customers' web sites will require significant resources in terms of personnel and equipment. Accordingly, it would be desirable to provides systems and methods for deploying software code, e.g., code usable to operate a web site, in a manner which avoids these problems.

SUMMARY

According to exemplary embodiments of the present invention, these and other drawbacks and difficulties of conventional code deployment techniques and systems are overcome by automating many of the portions of this process which have hitherto been performed manually.

For example, according to one embodiment of the present invention, a method for code deployment includes the steps of: displaying, at a first terminal, a user interface associated with deploying software code, authenticating access rights to deploy said software code, selecting, from the terminal, software code to deploy and then either uploading the selected software code to a staging server or requesting promotion of the selected software code from the staging server to a production server. The present invention thus provides secure, consistent, efficient, automated and scalable techniques for handling code deployment. Such techniques are particularly beneficial when employed in environments where many different customer web sites are automatically provisioned, monitored and controlled.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, features and advantages of the present invention will be readily understood by those skilled in the art by reading the following detailed description in conjunction with the drawings, in which:

Figure 1 is a block diagram representation of a client/server architecture in which the present invention can be employed; Figure 2 is illustrates a web site hosting environment in which the present invention can be employed;

Figure 3 is a flow diagram which illustrates a method for code deployment according to an exemplary embodiment of the present invention; Figure 4 is a flow diagram which illustrates a method for code deployment according to another exemplary embodiment of the present invention;

Figure 5 is a flow diagram which depicts method steps associated with a portion of the exemplary embodiment which begins in Figure 4; and

Figures 6(a)-6(e) are various GUI screens used in accordance with exemplary embodiments of the present invention.

DETAILED DESCRIPTION

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular systems, networks, software components, techniques, etc. in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, and circuits are omitted so as not to obscure the description of the present invention.

To provide some context within which to describe exemplary code deployment systems and methods according to the present invention, an Internet client-server system is illustrated in Figure 1. A client machine 10 is connected to a production host 14 via a network 12. The client machine can, for example, be a personal computer or any other type of device which can be connected to network 12, e.g., a cellular telephone. For illustrative purposes, network 12 can be the Internet, an intranet, an extranet or any other known network. Production host 14 includes a plurality of servers which are accessible by clients, one of which is illustrated by machine 10. A representative production host 14 is a computer comprising a processor 20, an operating system (OS) 22, and a web server application (Server App) 24, such as Apache or Netscape Enterprise Server. The web server 24 supports files and program code (collectively referred to as a "web site") which can include hypertext documents and objects. The production host 14 may also include other servers, e.g., application servers and database servers. A representative client machine can also include a browser 16, which those skilled in the art will appreciate can be one of a plurality of established software tools used to access hosts across the network 12. In the Internet paradigm, a network path to the web server 14 is identified by a predetermined address, e.g. , a URL as mentioned above, and can be pointed to by the browser 16. For reasons which will be apparent based on the discussion below, the production host 14 can be implemented together with a staging host 18, upon which the program code, hypertext documents, etc. can be tested prior to deploying on the production host 14. Thus, although not explicitly illustrated in Figure 1, those skilled in the art will appreciate that the staging host 18 will also include, for example, a web server, application server, database server, OS and processor that correspond to those found on the production host 14. Although advantageous for deploying software code between terminals, e.g., client machine 10 and production host 14 or staging host 18, in any environment, the present invention provides particular benefits when employed in a web site hosting environment wherein many web servers and/or staging servers are monitored and controlled collectively. Such an exemplary environment is depicted in Figure 2, wherein a plurality (1-N) of customer compartments 30 are shown as being connected to a central web site control and monitoring function 32. Each customer compartment 30 may have a large number of web servers, application servers and associated databases which support loading of the customer's web site, which loading is managed by the load balancer 33. A DNS server 34 may also be provided in the customer compartment as may other equipment not illustrated in Figure 2. The details of the central web site control and monitoring functionality 32 are beyond the scope of this discussion, however the interested reader is directed to U.S. Patent Application Serial

No. entitled "AUTOMATED PROVISIONING FRAMEWORK

FOR INTERNET SITE SERVERS" to Raymond Suorsa et al. filed on an even date herewith, the disclosure of which is incorporated here by reference, which is contains an example of such functionality. Although the compartments illustrated in Figure 2 depict physical separation of between different customer's equipment and physical proximity of the same customer's equipment, those skilled in the art will appreciate that logical compartmentation could be provided where such physical relationships between devices are nonexistent. Of more interest for the purposes of the present invention is the problem posed by trying to coordinate the deploying and updating of program code found on the multitude of web servers which are being managed, e.g., by the network operations center (NOC) represented in Figure 2 by the server 34, in the environment depicted in Figure 2 in a manner which is consistent, repeatable and highly automated. Exemplary embodiments of the present invention achieve these objects by providing techniques and systems wherein a customer and a NOC are provided with tools which interact to automate deployment of program code. A description of exemplary embodiments of the present invention will now be provided which begins from the customer or client machine 10' s perspective. In Figure 3, code deployment is initiated by pointed the browser 16 at the staging host 18. This can be done, for example, by typing in a predetermined address or URL into the data entry portion of the browser in a known manner. This will result in a graphical user interface (GUI) associated with software code deployment being displayed. Various exemplary screen displays associated with this GUI are reproduced as Figures 6(a)-6(e) and will be introduced as used below.

Next, at step 310, the customer authenticates his or her access rights by, for example, entering a user name and password. This step permits the system to ensure that the user of the client machine 10 that is pointed to the predetermined address or URL is only permitted to deploy program code or the like to the staging host 18 that is associated with that customer's web site. An exemplary GUI interface for data entry during this step is provided as Figure 6(a).

At step 312, the customer then chooses which type of code deployment will be performed during this session, i.e., deployment to the web server or to the applicaiton server associated with staging host 18. Next, at step 314, the GUI displayed on the client machine 10 as a result of pointing the browser at the predetermined address or URL displays a number of options for proceeding with the program code deployment. For example, the user can opt to upload a local bundle to the staging host 18 by, for example, operating a corresponding button on the GUI at step 316. As will be appreciated by those skilled in the art, a bundle refers to raw customer code that is in a non-installable format. The GUI can direct this process by providing a dialog box (step 318) for selection of the bundle or bundles to upload, an example of which is depicted in Figure 6(b) well as a progress bar (step 319) that provides feedback to the user of client machine 10 regarding the progress of the upload. As seen in Figure 6(b), database packages can be uploaded using a separate set of GUI interface elements. Additionally, various naming conventions and the like can be specified for consistent performance of the code deployment tool.

The GUI can also list a number of different bundles which have already been uploaded to the staging host 18 and which are available for packaging. The packaging process transforms the bundled files into a module which can be installed on the staging host 18, which transformation process will depend upon the type of operating system which is running on those servers. For example, the user can select a listed bundle at step 320, which results in the selected bundle being listed with additional detailed information, e.g., the creation date of the bundle, at step 322. Then, the system will determine the operating system which is running on the staging host 18. In the example illustrated in Figure 3, the types of packages contemplated are those associated with the Windows NT™ , WINDOWS 2000™ or Unix operating systems. However, those skilled in the art will recognize that other operating systems may be employed as the operating system on both the staging host 18 and production host 14. In either event, the system selects the appropriate path in the flow diagram for the operating system which is running on the host of interest and proceeds to create a package which is usable by that operating system in steps 324, 326 and 328.

Another option for a user operating the GUI which is displayed by pointing the browser 16 at the predetermined address or URL is to list packages for installation on the staging host 18 or promotion from the staging host 18 to the production host 14. This option follows the path which begins with step 330. If the user selects this option from the graphical user interface, then the system will list a directory which contains all of the packages that are available for installation on the staging host 18 or for promotion to the production host 14 from the staging host 18 at step 332. The user can then select one or more packages at step 332 which will lead to more detailed information being presented to the user at the client machine 10 in step 334. At that time, the user can confirm promotion of the selected packages to the production host 14 or installation to the staging host 18 by, for example, depressing a button displayed on the GUI.

These functions can, from a GUI perspective, be split into different screens. For example, if the user wishes to install or remove code packages from the staging host 18, then a screen such as that depicted in Figure 6(c) can be displayed. As seen therein, the user is able to select code packages for execution or removal. The user can also access host administrative functions, e.g., starting or stopping a server on the host, which may be needed prior to code package installation. When the "Execute Package" button in Figure 6(c) is depressed, the packaged code is installed into a suitable directory on the staging host 18. Similarly, Figure 6(d) provides an exemplary GUI for code package promotion. Specifically, the user is prompted to selected a code or database package for promotion and also to provide contact information, as well as a preferred time and date for promoting the code to the production host 14. Figure 3 described an exemplary embodiment of the present invention from the perspective of a user operating a graphical user interface at a client machine 10. However, code deployment according to the present invention can also be described from a process perspective beginning with the customer or client machine 10 and then transitioning to a point where the code deployment is handed off to the NOC for actual installation onto production hosts. This perspective of the present invention will now be described with respect to the exemplary embodiments in the flow diagrams of Figures 4 and 5.

In Figure 4, the method again begins with the customer or client machine 10 making a decision as to whether to move code to the staging host 18 or to test staging code that is already present on this host at block 400. Following the portion of the flow associated with moving code to the staging host 18, the process continues to step 402, wherein the user can create archive format packages at the client machine 10. These packages can then be uploaded using the graphical user interface described above to a predetermined directory on that customer's staging host 18. At step 404, the customer can also use the web interface to view all of the archive format packages currently located in the upload directory of their staging host 18. Then, from that list, the customer can select a particular archive format package (step 406) to be installed onto the staging host.

Step 408 represents a double check opportunity for the customer to insure that the selected package has been named and bundled correctly prior to installation on the staging host 18. This step can involve, for example, unbundling of the selected bundle for inspection by a plug-in script in the system, which script can be customized by the customer. Error checking can be adaptive such that repeated errors associated with bundling can be learned and embedded in the plug-in script invoked by the system to check that customer's bundles. If there is an error, then a message is returned to the customer indicating such (step 410) which provides the customer with an opportunity (step 412) to make the necessary changes to the selected archive file. Such an error causes the process to return to block 400. If, on the other hand, the package has been determined to be named and bundled correctly, the process continues to step 414 where the selected archive format package is retrieved from the upload directory and unpackaged at the staging host 18. Next, an installable format e.g., RPM, package is created and moved to an installable package directory at step 416 so that the appropriate tool can be launched to install the package onto the staging host for testing at step 418. Moving now to the second branch from step 400, wherein the user of client machine 10 has an opportunity to test the code resident on the staging host 18, the flow then moves to step 420. Therein, the client machine 10' s user can verify the files in the staging area to approve their readiness for promotion to the production host 14. If any changes have not been verified and approved at step 422, the flow moves back to step 412 to provide the customer with the opportunity to make additional changes. Otherwise, the flow continues to step 424, wherein the customer uses the web interface displayed on the client machine 10 to move the verified package to a "promote" directory. Finally, at step 426, the customer submits a code update request form, e.g., using the GUI illustrated in Figure 6(d), to the NOC at which time the customer's participation in the code deployment is terminated. At this time, the NOC then becomes the entity empowered to complete the code deployment process, which will now be discussed with reference to Figure 5.

Therein, at step 500, NOC personnel prepare for updating a production host 14 by performing either a registration or a deployment function. Moving first along the flow associated with registering the packages which have been received from the customer into the control and monitoring function 32, a ticket is entered to log the customer's request for promoting the package to the production host 14 at step 502. Next, at step 504, the customer is contacted to schedule the production code update so that both the web hosting company and the customer know precisely when the new production code is going to be moved onto the production host 14. Then, at step 506, NOC personnel launch a web interface associated with their functions which permits them to view all of the installable-format packages that have been saved in the pre- production directory. This can be accomplished by, for example, pointing a browser operating on a NOC computer to an address or URL which is different than the address or URL used by customers to perform the functionality described above with respect to Figure 4. Using a second port for NOC functions is intended to provide additional security. The NOC personnel can then select the installable-format like package identified by the customer to be deployed to production at step 508. The installable- format package is then retrieved and stored in a suitable identifying repository and can be registered with a database which contains various information associated with the control and monitoring functionality 32.

When a NOC personnel is ready to deploy a package to all appropriate production hosts associated with that particular customer, the flow then departs the right-hand side of block 500. At step 514 a particular host or hosts is selected for updating. That host(s) is then stopped for package installation at step 516. A user interface can then be used to select the package for installation onto the now stopped production machine (step 518) and the host can then be restarted after package install (step 520). If all of the production hosts associated with the selected package have not been updated at step 522, the flow loops back to select another host for updating and steps 516 through 520 are repeated. Otherwise, the host restart tool is initiated at step 524. The customer is then notified that the production site as been updated, e.g. , telephonically or via e-mail, at step 526 and the ticket which was generated at step 502 can be closed and logged out electronically to complete the process at step 528. An exemplary GUI associated with these NOC functions is provided as Figure 6(e). The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present mvention. Thus the present invention is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. All such variations and modifications are considered to be within the scope and spirit of the present mvention as defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method for controlling deployment of software code comprising the steps of: displaying, at a first terminal, a user interface associated with deploying said software code; selecting, from said first terminal, said software code to deploy; and selectively, based upon input via said user interface, performing one of the steps of:

(a) uploading said selected software code to a staging host (b) converting said selected software code to an installable format and installing said selected software code on said staging host; or

(c) promoting said selected software code from said staging host to a production host.

2. The method of claim 1, wherein said step of displaying is responsive to the step of: pointing, from said first terminal, a browser at a first predetermined address.

3. The method of claim 1, further comprising the step of: creating a package at said first terminal.

4. The method of claim 3, wherein said package is a zip package.

5. The method of claim 1, wherein said selectively step selects step (c) and further comprising the steps of: remotely installing said selected software code onto said production host.

6. The method of claim 1, wherein said selectively step selects step

(b) and further comprising the step of: testing said software code on said staging host.

7. The method of claim 1, wherein said selectively step selects step (c) and further comprising the step of: contacting a user associated with said first terminal to confirm promotion of said software code from said staging host to said production host.

8. The method of claim 1, wherein said selective step selects step

(c) and further comprising the steps of: displaying, at a second terminal, software packages in a pre-production directory; and selecting one of said software package to promote to said production host.

9. The method of claim 8, wherein said second terminal is part of a network operations center of a web site hosting facility.

10. The method of claim 8, wherein said step of displaying at said second terminal further comprises the step of: pointing, from said second terminal, a browser at a predetermined address to launch a web interface that displays said software packages in said pre- production directory.

11. The method of claim 2, wherein said selective step selects step (c) and further comprising the step of: pointing, from a second terminal, a browser at a second predetermined address which is different than said first predetermined address to launch a web interface that displays said software code in a pre-production directory.

12. The method of claim 1, further comprising the step of: authenticating access rights to deploy said software code.

13. A graphical user interface which interacts with a computer to facilitate data transactions comprising: means for selecting, from said first computer, software code to deploy; and means for selectively, based upon input from a user, performing one of the steps of:

(a) uploading said selected software code to a staging host (b) converting said selected software code to an installable format and installing said selected software code on said staging host; or

(c) promoting said selected software code to a production host.