Testing and deploying targeted versions of application libraries within a software application

Methods and apparatuses are described for testing and deploying targeted versions of application libraries within a software application. A computing device selects a software application comprising application libraries each associated with a current version identifier. The computing device identifies a target version of one or more application libraries, the target version associated with a different version identifier than the current identifier. The computing device defines a software application build for the software application incorporating the identified target versions of the application libraries, and deploys the application build to a test computing environment. The computing device executes tests of the software application build in the test environment, and captures test execution data for the target versions of the libraries in the software application build. The computing device deploys the software application build including the target versions of the application libraries to a production computing environment based upon the test execution data.

TECHNICAL FIELD

This application relates generally to methods and apparatuses, including computer program products, for testing and deploying targeted versions of application libraries within a software application.

BACKGROUND

Due to the flexibility, re-usability, and cost of open source and/or third-party software modules, artifacts, and libraries, developers now frequently incorporate such software into their applications, either directly or as application dependencies—and many of these modules, artifacts, and libraries are publicly available for download and use without restriction. For example, a typical web application may use on the order of thirty to fifty third-party libraries to accomplish various lower level program functions. As can be appreciated, these libraries may need to be periodically upgraded for various reasons, including availability of new features, resolving functional issues, security issues, and end of life/support considerations.

Upgrading and/or updating applications and their associated artifacts and libraries can be a time-consuming process that typically involves determining one or more versions of a library to use, updating third-party libraries with the determined version(s), generating a new application build, deploying to one or more testing or production environments and performing functional and performance-related tests to ensure the libraries are working properly within the application and do not impose any risks of data loss or security deficiencies. Generally, existing development systems that provide for updating of libraries approach the problem as requiring specific identification of each upgraded library version by a developer or system administrator. This approach can be time-consuming and cumbersome, requiring the developer or system administrator to individually determine, select and test each upgrade for every library being used—even when a plurality of libraries may have common characteristics that could be updated according to the same technical considerations.

SUMMARY

Therefore, what is needed are methods and systems that enable the automatic execution of library version deployment scenarios based upon one or more characteristics associated with the libraries being upgraded, such as end-of-life attributes, critical vulnerabilities, deprecation or dependency characteristics and the like. The techniques described herein advantageously provide for the automated identification of upgraded library versions for multiple libraries in a given application, integration of the upgraded libraries into a software application build, deployment of the software application build to a test computing environment, and execution of the deployed build to identify issues or errors resulting from use of the upgraded libraries. These techniques beneficially allow for technical staff to quickly select libraries for upgrading and determine whether to deploy such libraries to a production build based upon the testing results, without having to conduct a separate test for each library and integrate them individually into a particular software application build. The methods and systems described herein further provide an intuitive front-end user interface for developers to manage the library upgrade process for one or more applications without the need to manually generate complex scripts or build instructions for the library upgrades.

The invention, in one aspect, features a system for testing and deploying targeted versions of application libraries within a software application. The system comprises a computing device with a memory for storing computer-executable instructions and a processor that executes the computer-executable instructions to select a software application comprising one or more application libraries each associated with a current version identifier. The computing device identifies a target version of one or more of the application libraries, the target version associated with a different version identifier than the current version identifier. The computing device defines a software application build for the software application, the software application build incorporating the identified target versions of the application libraries. The computing device deploys the software application build to a test computing environment. The computing device executes one or more tests of the software application build in the test computing environment. The computing device captures test execution data for one or more target versions of the application libraries in the software application build. The computing device deploys the software application build including the target versions of the application libraries to a production computing environment based upon the test execution data.

The invention, in another aspect, features a computerized method of testing and deploying targeted versions of application libraries within a software application. A computing device selects a software application comprising one or more application libraries each associated with a current version identifier. The computing device identifies a target version of one or more of the application libraries, the target version associated with a different version identifier than the current version identifier. The computing device defines a software application build for the software application, the software application build incorporating the identified target versions of the application libraries. The computing device deploys the software application build to a test computing environment. The computing device executes one or more tests of the software application build in the test computing environment. The computing device captures test execution data for one or more target versions of the application libraries in the software application build. The computing device deploys the software application build including the target versions of the application libraries to a production computing environment based upon the test execution data.

Any of the above aspects can include one or more of the following features. In some embodiments, identifying a target version of one or more of the application libraries comprises receiving, from a remote computing device, a selection of the target version of the application library and retrieving, from a library database, the target version of the application library for use in the software application build based upon the selection. In some embodiments, identifying a target version of one or more of the application libraries comprises generating one or more target version scenarios for display on the remote computing device, each target version scenario comprising a definition of which target version of the application library to include in the software application build; receiving a selection of one of the target version scenarios from the remote computing device; and retrieving, from a library database, the target version of the application library for use in the software application build based upon the attribute in the selected target version scenario.

In some embodiments, generating one or more target version scenarios comprises determining one or more common attributes for a plurality of application libraries; and generating the target version scenarios based upon the common attributes. In some embodiments, the common attributes comprise an end of life attribute, a critical vulnerability attribute, a deprecation attribute, or a dependency attribute. In some embodiments, the definition of which target version to include in the software application build comprises a latest version of the application library, a latest sub-version of the application library, or a latest version of the application library with no critical vulnerabilities.

In some embodiments, the test execution data comprises an error generated by one or more of the target versions of the application libraries in the software application build, a missing data value generated by one or more of the target versions of the application libraries in the software application build, or a test failure message generated by one or more of the target versions of the application libraries in the software application build. In some embodiments, deploying the software application build including the target versions of the application libraries to a production computing environment based upon the test execution data comprises determining that one or more of the tests had successful execution for the software application build in the test computing environment.

In some embodiments, the computing device determines that one or more of the tests did not have successful execution for the software application build in the test computing environment and reverses deployment of the software application build including the target versions of the application libraries to the production computing environment. In some embodiments, deploying the software application build to a test computing environment comprises provisioning the test computing environment, including initializing one or more virtual machines for execution of the software application build. In some embodiments, the computing device tears down the test computing environment upon conclusion of the test execution and results capture.

DETAILED DESCRIPTION

FIG.1is a block diagram of a system100for testing and deploying targeted versions of application libraries within a software application. The system100includes an application build environment that comprises a build server computing device102athat includes a user interface module104a, a scenario identification module104b, a build generation module104c, and a plurality of databases—artifact repository108a, library database108b, and source code repository108c. The system further includes an application test environment that is coupled to the application build environment via a communications network106. The application test environment comprises a server computing device102bthat includes an application104d, an environment provisioning module104e, a test execution module104f, and an alerting module108e. The build server computing device102aand the test server computing device102bare each coupled to the client computing device103via network106.

The build server computing device102aconnects to the communications network104in order to communicate with the test server computing device102band the client computing device103to perform functions relating to testing and deploying targeted versions of application libraries within a software application. In some embodiments, the build server102ais a combination of hardware, including one or more special-purpose processors and one or more physical memory modules, and specialized software modules—including user interface module104a, scenario identification module104b, and build generation module104c—that are executed by a processor of the build server102a, to receive data from other components of the system100, transmit data to other components of the system100, and perform functions relating to testing and deploying targeted versions of application libraries within a software application as described herein It should be appreciated that other types of computing devices that are capable of connecting to the components of the system100can be used without departing from the scope of invention. AlthoughFIG.1depicts a single build server102a, it should be appreciated that the system100can include any number of build servers. In some embodiments, the build server102ais associated with a source code change management platform, software application development platform, and/or an issue tracking platform (such as Jira™ from Atlassian, Inc.), and the build server102ais configured to coordinate with test server computing device102bto generate a software application build and deploy the software application build in the application test environment as described herein.

The test server computing device102bconnects to the communications network104in order to communicate with the build server computing device102aand the client computing device103to perform functions relating to testing and deploying targeted versions of application libraries within a software application. In some embodiments, the test server102bis a combination of hardware, including one or more special-purpose processors and one or more physical memory modules, and specialized software modules—including application104d, environment provisioning module104e, test execution module104f, and alerting module104g—that are executed by a processor of the test server102b, to receive data from other components of the system100, transmit data to other components of the system100, and perform functions relating to testing and deploying targeted versions of application libraries within a software application as described herein It should be appreciated that other types of computing devices that are capable of connecting to the components of the system100can be used without departing from the scope of invention. AlthoughFIG.1depicts a single test server102b, it should be appreciated that the system100can include any number of test servers. In some embodiments, the test server102bis associated with an automation testing software platform or tool (such as Selenium™ available from selenium.dev or Sahi™ Pro available from sahipro.com), and the test server102bis configured to coordinate with build server computing device102ato provision the application test environment, deploy a software application build in the application test environment, execute tests against the software application build, and capture test results associated with the test execution as described herein.

The client computing device103connects to the communications network104in order to communicate with the build server computing device102aand the test server computing device102bto perform functions relating to testing and deploying targeted versions of application libraries within a software application. Exemplary client computing devices103include but are not limited to desktop computers, laptop computers, tablets, mobile devices, smartphones, and internet appliances. It should be appreciated that other types of computing devices that are capable of connecting to the components of the system100can be used without departing from the scope of invention. AlthoughFIG.1depicts a single client computing device103, it should be appreciated that the system100can include any number of client computing devices.

The communication network106enables the other components of the system100to communicate with each other in order to perform the process of detecting vulnerabilities associated with a software application build as described herein. The network106may be a local network, such as a LAN, or a wide area network, such as the Internet and/or a cellular network. In some embodiments, the network106is comprised of several discrete networks and/or sub-networks (e.g., cellular to Internet) that enable the components of the system100to communicate with each other. In some embodiments, a network that connects the build server102ato the test server102bis different from a network that connects the client computing device103to the build server102aand/or test server102b

The server computing devices102aand102bare each a combination of hardware, including one or more special-purpose processors and one or more physical memory modules, and specialized software modules—such as modules104a-104cfor server102a, and modules104d-104gfor server102b—that are executed by a processor of the respective server computing device102aand102b, to receive data from other components of the system100, transmit data to other components of the system100, and perform functions for testing and deploying targeted versions of application libraries within a software application as described herein. In some embodiments, the modules104a-104gare specialized sets of computer software instructions programmed onto a dedicated processor in the respective server computing device102aor102band can include specifically-designated memory locations and/or registers for executing the specialized computer software instructions. Further explanation of the specific processing performed by the modules104a-104gwill be provided below.

Although the modules104a-104care shown inFIG.1as executing within the same server computing device102a, and modules104d-104gare shown as executing within the same server computing device102b, in some embodiments the functionality of the modules104a-104gcan be distributed among a plurality of server computing devices and/or located on the same computing device. As shown inFIG.1, the server computing device102aenables the modules104a-104cto communicate with each other in order to exchange data for the purpose of performing the described functions, and similarly the server computing device102benables the modules104d-104gto communicate with each other in order to exchange data for the purpose of performing the described functions. It should be appreciated that any number of computing devices, arranged in a variety of architectures, resources, and configurations (e.g., cluster computing, virtual computing, cloud computing) to perform the functions of the server computing devices102aand102b.

The databases108a-108ccomprise transient and/or persistent memory for data storage, that is used in conjunction with testing and deploying targeted versions of application libraries within a software application as described herein. Generally, the databases108a-108care configured to receive, generate, and store specific segments of data relating to functions performed by the modules104a-104g, the build server102aand/or the test server102bmore generally, and/or the client computing device103. In some embodiments, all or a portion of the databases108a-108ccan be integrated within the build server102a, or located on a separate computing device or devices, where the separate devices are in proximity to the server computing device102a(e.g., connected via cabling or other localized connection) and/or located via remote network connection (e.g., network106) to the server computing device102a. In one example, the databases108a-108ccan each comprise a database such as MySQL™ available from Oracle Corp. of Redwood City, California or MongoDB available at mongodb.com. In another example, the databases110a-110ccan be based upon a platform such as Cassandra™ available from The Apache Software Foundation (cassandra.apache.org). Other types of ‘big data,’ scalable databases and/or customized database frameworks can be used within the scope of the technology described herein.

FIG.2is a flow diagram of a computerized method200of testing and deploying targeted versions of application libraries within a software application, using the system100ofFIG.1. The client computing device103connects to the user interface (UI) module104aof build server102ain order to initiate generation, deployment, and testing of a software application build that includes upgraded or updated libraries as described herein. The UI module104areceives input from the client computing device103to select (step202ofFIG.2) a software application comprising one or more application libraries each associated with a current version identifier. The UI module104agenerates a user interface screen for display on the client computing device103that lists the software application projects/tech stacks that are available for modification and testing as described herein.FIG.3is a diagram of an exemplary software application selection user interface300as generated by the UI module104a. As shown inFIG.3, the user interface300includes a list of software application projects from which the user can select. In some embodiments, each item in the list is a software application project that corresponds to certain application functionality. For example, the first item in the list is a software application project with the identifier ‘ap109960-ssc-apps-platformmessaging.’ The list comprises the software application repository302, a branch type304of the software application, and a branch identifier306of the software application. The user at client computing device103can select a specific branch of the software application code to be modified and tested using, e.g., the drop down boxes as shown inFIG.3. In some embodiments, the UI module104aretrieves the list of software applications from the source code repository108cfor generation of the user interface300. To select a software application project, the user can click the empty box next to the desired project (e.g., box308) to check the box and instruct the UI module104ato go to the next screen (e.g., via a button or other user interface element, not shown).

When one or more software application project selections are received from the client computing device103, the user interface module104acan retrieve an identification of application artifacts for the selected software application project(s) from, e.g., artifact repository108a—such as data objects, dependencies, code modules, libraries and the like. The user interface module104agenerates a user interface screen for display on the client computing device103that lists the identified artifacts for the selected software application project, including any application libraries.FIG.4is a diagram of an exemplary artifact selection user interface400as generated by the UI module104a. As shown inFIG.4, the identifier for the selected software application project fromFIG.3(i.e. ‘ap109960-ssc-apps-platformmessaging’) is displayed at the top of the user interface (as element402). The user interface400includes a list of application artifacts, such as libraries and other dependencies, as retrieved from e.g., artifact repository108a. The UI module108aalso displays certain metadata corresponding to each artifact that is currently integrated into the software application project: an artifact ID404, a group ID, and a current version408. For each artifact, the UI module108aretrieves artifact version-specific metadata from, e.g., library database108bfor inclusion as the available versions element410in the user interface400. As shown inFIG.4, the available versions element410comprises a selectable feature that enables a user at client computing device103to review one or more available versions of the corresponding artifact and to select a specific artifact version to integrate into the software application build. As can be appreciated, the one or more available versions can include newer versions, previous versions, alternate versions, beta versions, and so forth. As an illustrative example, the library can be upgraded to a newer version or rolled back to a previous version depending upon the requirements of the testing and deployment process.

For example, the artifact ‘ssc-common-dao-spring’ has a current version of 1.39.0-SNAPSHOT. If the user at client device103wants to change or update the version of ssc-common-dao-spring in the build, the user can select the UI feature410for ssc-common-dao-spring and the UI module104apresents the user with a list or drop-down menu of different versions of the library that can be integrated into the build.FIG.5is a diagram of an exemplary version selection menu500as generated by the UI module104a. As shown inFIG.5, when a user selects the feature410for a particular artifact, the UI module104agenerates a menu comprising both a list of available versions for the artifact and a list of scenario-based upgrades that can be carried out by the user. For example, the menu500displays a list of version upgrades for the artifact ‘ssc-common-dao-spring’—specific versions 1.39.0-SNAPSHOT (current version, underlined for ease of reference by the user), 1.38.0-SNAPSHOT (earlier version), and 1.41.0-SNAPSHOT (newer version) (elements502inFIG.5), along with several scenario-based version changes that do not directly specify a particular version number: Update to Latest Version, Update to Latest Point-Version, and Update to Latest Version with No Critical Vulnerabilities (elements504inFIG.5). The user can select either a specific version number or one of the scenario items; for the latter, the scenario identification module104bdetermines one or more scenarios that are applicable to the given artifact (and/or to the software project more generally) and includes the determined scenarios in the menu500. Use of the scenarios advantageously relieves the burden from the user to manually identify and select the proper version number for one or more libraries in the software application build; instead the user can simply select a scenario and the scenario identification module104bcan execute an algorithm to automatically identify the library version that corresponds to the selected scenario. Other types of scenarios in addition to the above can be contemplated for use with the systems and methods described herein, e.g., roll back scenarios, and so forth.

For example, the user may not know which version of the ssc-common-dao-spring library is the latest version with no critical vulnerabilities. Instead of having to research the information independently before building and deploying a software application for testing, the user can simply select the ‘Update to Latest Version with No Critical Vulnerabilities’ scenario from the menu500and the scenario identification module104btakes care of evaluating the library metadata from library database108band identifying the version number of the ssc-common-dao-spring library that satisfies the scenario. In one example, the scenario identification module104blooks for specific metadata in the library database108bthat indicates which version(s) of a given library have no critical vulnerabilities. The library database108bcan be configured to store certain vulnerability-related information retrieved from external data sources (such as those provided by software security organizations or governmental entities—examples of such data sources are the National Vulnerability Database (NVD) maintained by the National Institute for Standards and Technology (https://nvd.nist.gov/) or the CVE Details data source maintained by MITRE Corp. (https://www.cvedetails.com/)) relating to known vulnerabilities for storage in the library database108. The scenario identification module104bcan rely on the above information (or other information) to determine which version(s) of a library do not have critical vulnerabilities. Then, using this subset of library versions, the scenario identification module104bcan identify the latest version (e.g., using the version numbers and/or a build/release date for the library versions) that does not have any critical vulnerabilities and use that version to integrate into the application build for testing.

Turning back toFIG.3, the user at client computing device103can continue down the list until all of the changed versions and/or desired version scenarios for specific libraries are selected. In some embodiments, when a user does not select a different available version or scenario (either because the user selected in410the same version as current, the user did not select any versions in410, or the scenario identification module104bdetermines that a scenario selected by the user results in the same version as current), the current version of the corresponding artifact is used for the software application build. In order to integrate the selected available version of the artifact into the software application build, the user can select the add-to-cart button412for each such artifact and instruct the UI module104ato go to the next screen (e.g., via a button or other user interface element, not shown).

In some embodiments, the UI module104aalso displays a severity indicator414for each artifact that provides a color-coded indication to the user of which libraries may be in need of urgent or critical updates (due to end-of-life, security vulnerabilities, deprecation, changes to other dependencies, etc.) and which libraries are not in need of such urgent updates. For example, critical updates may be displayed in red, urgent updates may be displayed in yellow, and non-urgent updates may be displayed in green. The severity indicator can be grey or blank if the current version of the artifact is the preferred version to use. The UI module104acan collect metadata about the artifacts from library database108bthat relate to end-of-life, security vulnerabilities, deprecation, changes to other dependencies, and the UI module104acan convert this metadata into the color used in the severity indicator414. The severity indicator414can draw the user's attention to which artifact(s) may be priorities for updating in the upcoming test build.

Turning back toFIG.4, in some embodiments the UI module104aincludes a user interface element416in user interface400that enables a user to select an update scenario for any or all artifacts in the list. For example, the scenario options listed above in menu500can also be represented in element416for selection by the user. Instead of clicking through each available version element410in the interface, the user can simply select a desired scenario from element416and the scenario identification module104bautomatically evaluates whether a different version of each artifact in the project exists that meets the requirements of the scenario. If so, the scenario identification module104bcan select the artifact version for inclusion in the build. In some embodiments, the user can click on the Add All button418to automatically include all artifact versions that have changed in the interface400to the upcoming test build.

Turning back toFIG.2, after receiving the library version and/or update scenario selections from the UI module104aand/or scenario identification module104b, the build generation module104cidentifies (step204) a target version of one or more of the application libraries, the target version associated with a different version identifier than the current identifier. For example, the build generation module104ccan retrieve identification of specific library version numbers that will be included in the next test build from the other modules104a-104band/or databases110a-110cand locate and/or retrieve the associated library versions from, e.g., databases110a-110cand/or external data sources or feeds.

In some embodiments, the UI module104agenerates a confirmation interface to enable the user at client computing device102to confirm that the artifact version selections chosen by the user are accurate and complete.FIG.6is a diagram of an exemplary confirmation interface600as generated by the UI module104a. As shown inFIG.6, the interface comprises a list of library version updates that were selected by the user, including data elements such as the project identifier/name602, the artifact ID604, and the version upgrade or change606. This way, the user can quickly review and confirm the desired version changes prior to submitting them for the generation of a software build. The interface600also includes a button608for each version upgrade that enables the user to remove the upgrade from the build. Once the user is satisfied with the changes, the user can click the submit button610to generate a software build as described below.

Using the updated library versions, the build generation module104cdefines (step206) a software application build for the software application incorporating the identified target versions of the application libraries, dependencies, and/or artifacts identified by the system100as described above. In one example, the build generation module104ccan generate build instructions for the software application using an existing build image (e.g., via cloning the build) and/or a newly-created build image and update the build image to refer to and otherwise incorporate the target library versions (instead of the currently-used versions). It should be appreciated that, in some embodiments, the build generation module104ccan generate multiple builds for a given software application that may vary in certain respects (e.g., versioning, features added, dependencies, deployment platform or device form factor, etc.) based upon the desired testing parameters and run tests against each of these builds.

In one example, at least the source code repository110c, the library database110b, and/or the build generation module104c, can be part of a source code development and management platform that tracks changes in source code and other related files during the development of a software application (e.g., a Java™ application for deployment in a production computing environment), including but not limited to a source code control system and/or a version control system that is coupled to a development environment which enables users to access an application's code base to make changes (e.g., bug fixes, improved and/or additional functionality, and the like). In one embodiment, the server computing devices102aand/or102bare part of an Apache Maven™ deployment (https://maven.apache.org); Maven™ is a software project management tool that utilizes the concept of a project object model (POM) to manage a Java™ application build and its related dependencies. It should be appreciated that other types of software project management tools and software development platforms can be used within the scope of the invention. The source code repository108ccan store a build definition file that associates one or more source code files to a particular application build. The build generation module108acan use the build definition file to retrieve the necessary components from the source code repository110cor other locations—including the updated versions of the libraries—and generate one or more executable application builds for the particular software application.

As described above, an application build typically has one or more application dependencies that are required to be integrated into, linked with, or otherwise associated with the application build in order for the software application to function properly. As can be appreciated, many of the embodiments described herein relate to application libraries, but the same techniques can be applied to other application dependencies. Examples of such application dependencies include, but are not limited to, libraries, frameworks, and other types of modules that contain code, files, and/or functions. An example of an application dependency for a Java™ application is a Java™ Archive (JAR) file. These application dependencies can include open source code and/or third-party licensed code obtained from remote computing devices at build time or stored in the artifact repository108afor use during application builds. The build definition file and/or the build generation module104ccan identify the application dependences during the process of generating the software application build and retrieve the necessary dependency components (such as updated versions of libraries) in order to complete generation of the build(s). In some embodiments, the build generation module104ccan generate an output file (e.g., POM.xml in Maven™) that stores the determined application dependencies.

Once the software application builds with the updated library versions are generated, the build generation module104cdeploys (step208) the software application build(s) (e.g., application104d) to the test server computing device102bfor test execution. In one example, the build generation module104ctransmits the executable application build(s) to the test server102band the environment provisioning module104eanalyzes the build file(s) to provision a testing environment to instantiate each application build and run tests against the build. In some embodiments, the environment provisioning module104ecan provision one or more virtual machines (e.g., in a cloud framework) on the test server102band/or other computing devices in the testing environment and deploy the software application build to the virtual machines. In addition, the environment provisioning module104ecan provision peripheral infrastructure needed to carry out the application tests (e.g., web servers, containers, databases, disk drives, etc.).

Once the testing environment is provisioned, the test execution module104fexecutes (step210) one or more tests of the deployed software application build(s) in the testing environment. For example, the test execution module104fcan select one or more test scripts corresponding to a test suite selected by the user at client computing device103and execute the test scripts against the application build(s). Execution of the test scripts can include, but is not limited to, activation of user interface elements and related functionality in the application, introduction of data into algorithms and/or workflows of the application, logging of script execution results and error messages, and so forth. The test execution module104fcaptures (step212) test execution data for one or more target versions of the application libraries in the software application build. For example, a target version of an application library may not be compatible with existing code in the software application and when invoked or executed, the library can throw error messages which are captured by the test execution module104f. In this instance, the test execution module104flogs these error messages and test results in a log file stored on the test server102b.

Upon completion of the test execution, the alerting module104ganalyzes the test execution data (e.g., logs, error messages, etc.) generated by the test execution module104fto determine whether any target versions of the application libraries were executed during the testing and if so, whether the target versions caused issues or errors in the software application. For example, the alerting module104gcan extract the relevant target library information (e.g., artifact ID, group ID, artifact name, version number, etc.) recorded in the log file and parse the library information to determine, e.g., which libraries are problematic and should not be deployed to a production computing environment as part of the application build. The alerting module104gcan then generate one or more warning messages based upon the log analysis and transmit the vulnerability warning messages to a user device (e.g., client computing device103)—so that developers, system administrators, and other Quality Assurance staff are made aware of the invocation of the library and the related errors and if necessary, take steps to roll back the target library to a different version or avoid using the target library version in upcoming production builds. In another example, the alerting module104fcan automatically generate a library version remediation ticket in the corresponding software application development system (e.g., an issue tracking system such as Jira™ from Atlassian, Inc.) that identifies the target library version using the relevant information obtained from the log file and assigns the ticket to a developer that can adjust the library version if required.

When the test execution is complete and no issues are found with the target libraries as deployed in the application build, the build server102acan be configured to deploy (step216) the software application build that includes the target versions of the application libraries to a production computing environment based upon the test execution data. For example, if no errors are detected and/or only minor, non-critical errors are detected from execution of the target library versions, the build server102acan determine that the application build using the target library versions can be safely deployed to a production computing environment. In this way, the systems and methods described herein beneficially enable automated selection of target library versions, generation of test builds using those target libraries, deployment and execution of the test builds in a test environment, determination of any errors or issues presented by the target library versions and deployment of certain application builds to a production environment when the target libraries are found to be acceptable. Developers and other users can avoid spending a significant amount of time in determining specific library versions to use; instead, the systems and methods advantageously implement algorithms to select library versions based upon library update scenarios selected by the users.

Finally, at the conclusion of the test execution process, the environment provisioning module106ecan be configured to tear down the provisioned testing environment, including any virtual machines, containers, or other resources that were generated as part of creating the test environment described above. This conserves the availability of computing resources in the test server102band enables other users to provision testing environments, which can be especially beneficial in a cloud-based testing framework.

To provide for interaction with a user, the above described techniques can be implemented on a computing device in communication with a display device, e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor, a mobile device display or screen, a holographic device and/or projector, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer (e.g., interact with a user interface element). Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, and/or tactile input.