Risk based profiles for development operations

A method, computer program product, and system for risk monitoring of continuous software delivery include a first plurality of test data. The first plurality of test data is associated with one or more software components. In response to receiving a changelog, a change in the received plurality of test data is determined. A risk profile for the one or more software components is generated, in response to receiving the first plurality of test data and the received changelog. A component code graph is generated, based on the risk profile associated with the one or more software components and a risk value associated with the generated risk profile is calculated, based on the component code graph.

BACKGROUND

The present invention relates generally to the field of risk management, and more particularly to risk profiles associated with software components in a development operation.

As a part of the continuous delivery (CD) process in a development operation (DevOps), development team continuously fix defects & release new features to staging & eventually to production. The DevOps team have to manage updates, test updates and maintain awareness of any issues reported from the field. The engineers in the DevOps team may depend on metrics, events, and logs collected by a monitoring system to predict, detect, isolate, and resolve issues in the software.

In order to reduce risk of failure, the DevOps team may use a monitoring system to increase the quality & quantity of the data collected (metrics, events, logs), by increasing the frequency of data collection or depth of data collected (information and trace messages in addition to error, warning messages); however, this may impact the overall performance of the system.

The DevOps team typically makes a trade-off between performance & risk factors. Manually manipulation of the monitoring system at different points in time, may allow the DevOps team to support the subject application or service. It may arise, however, that high risk components are not monitored sufficiently, as well as low-risk components under aggressive monitoring.

SUMMARY

Embodiments of the present invention disclose a method, computer program product, and system for risk monitoring of continuous software delivery. A first plurality of test data is received, the first plurality of test data being associated with one or more software components. In response to receiving a changelog, a change in the received plurality of test data is determined. A risk profile for the one or more software components is generated, in response to receiving the first plurality of test data and the received changelog. A component code graph is generated, based on the risk profile associated with the one or more software components and a risk value associated with the generated risk profile is calculated, based on the component code graph.

DETAILED DESCRIPTION

Embodiments of the present invention will now be described in detail with reference to the Figures. Referring toFIG. 1, a functional block diagram illustrating a distributed data processing environment, generally designated100, is shown, in accordance with one embodiment of the present invention. Distributed data processing environment100includes server110, developer device130, testing device150and field device170, interconnected through network180.

Network180may include permanent connections, such as wire or fiber optic cables, or temporary connections made through telephone or wireless communications. Network180may represent a worldwide collection of networks and gateways, such as the Internet, that use various protocols to communicate with one another, such as Lightweight Directory Access Protocol (LDAP), Transport Control Protocol/Internet Protocol (TCP/IP), Hypertext Transport Protocol (HTTP), Wireless Application Protocol (WAP), etc. Network180may also include a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN).

Each of server110, developer device130, testing device150, and field device170may be a laptop computer, tablet computer, netbook computer, personal computer (PC), desktop computer, smart phone, or any programmable electronic device capable of an exchange of data packets with other electronic devices, for example, through a network adapter, in accordance with an embodiment of the invention, and which may be described generally with respect toFIG. 4below. In various embodiments, server110may be a separate server or series of servers, a database, or other data storage, internal or external to developer device130, testing device150, and field device170, of distributed data processing environment100.

Server110includes server application120, as described in more detail in reference toFIG. 2. In various embodiments, server110operates generally to receive a plurality of data associated with one or more software components, for example, software artifacts, determine a change in the received data and recording the change in received data, generate risk profiles for each software components, generates a component code graph, calculated and assigns a risk value to each generated risk profile, and dynamically adjusts the risk value based on received new data. Server110may host applications, for example, server application120, which may process and/or store data received via server110. In various embodiments, received data, or software artifacts, may include development artifacts, test artifacts, and/or field data artifacts.

Developer device130operates generally to generate and communicate development artifacts to server application120via server110. In various embodiments, development artifacts may include, for example, software code from reverse engineering or development configurations for various software components. In various embodiments developer device130may generate a code component graph which represents all code associated with a particular component. Code generated on developer device130may change, and those changed may generate logs, for example, build logs or changelogs. Build logs may trigger an annotation in the generated component code graph. Developer device130may communicate data associated with components, component code graph data, and/or change logs to server application120via server110or testing device150.

Testing device150operates generally to receive code and component data, and generate and communicate test artifacts to server application120via server110. In various embodiments, testing device150may receive code and component data from developer device130. Testing device150may perform various functional verification testing (FVT) on received code and generate test artifacts. Test artifacts may be, for example, log-adjacency-changes configuration command instructions that generate log sequence or log messages that indicate software failures. Testing device150may generate a failure or defect history based on the log messages indicating failures and associate log messages with received components. Failure history, associated with various components, may be communicated to server application120via server110or field device170.

Field device170operates generally to receive failure logs associated with software components and generate and communicate operation or field data artifacts to server application120via server110. In various embodiments field device170may receive failure log data and associated component data from testing device150. In various embodiments, field device170may generate incident data, which correlate the incidence of failure of a component with the component that caused the failure. In various embodiments, field device170may perform natural language data mining of social media and analyze social media websites for comments indicating failures or performance issues of any of the logged components. Field device170may communicate incident data and/or social media comments to server application120, via server110through network180.

Network180can be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and can include wired, wireless, or fiber optic connections. In general, network180can be any combination of connections and protocols that will support communications between server110, developer device130, testing device150, and field device170.

Referring toFIG. 2, a functional block diagram illustrating the components of server application120is shown, within distributed data processing environment100, in accordance with an embodiment of the present invention. Server application120includes receiving module200, profile module210, risk module220, and monitoring module230.

Receiving module200operated generally to receive software artifacts and related data, analyze received data, and communicate analyzed data to profile module210. In various embodiments, receiving module200may receive code with associated component data, component-code graph data, failure histories, incident data, and/or social media comments. In various embodiments, receiving module200may receive code with associated component data and component-code graph data from developer device130, failure histories or failure logs, from testing device150, and incident data, and/or social media comments from field device170. Receiving module200may determine received data that meets a risk criteria, in various embodiments the risk criteria is predetermined or procedurally generated by receiving module200by analyzing the received data using natural language analysis. Data that meets a risk criteria may be stored in memory or communicated to profile module210for further processing. Receiving module200may periodically check for new data or new risk criteria in order to dynamically determine if received data meets risk criteria to be communicated to profile module210.

Profile module210operates generally to receive data, generate risk profiles associated with one or more components, and communicate data and/or generated profiles. In various embodiments, profile module210may receive code with associated component data, component-code graph data, failure histories, incident data, and/or social media comments from receiving module200, which meet a risk criteria. Profile module210may generate a risk profile for each component that is associated with received data. In various embodiments, the risk profile may include, for example, metrics from the received component-code graph data, where the higher the level of component-code dependency the higher the risk.

In various embodiments, received code with an associated change may be included in the generated risk profile, for example, the more changes in determined in the received code, the higher the risk. Profile module210may also include failure histories in which the length or nature of the failure history may increase or decrease the risk associated with that component. Profile module210may analyze incident data in order to determine if the incidence associated with a component is above a frequency threshold and profile module210may increase the risk associated with that profile. In various embodiments, the frequency threshold may be predetermined or calculated my profile module210, based on previous profiles histories, or another module within or without server application120. Profile module210may use natural language analysis to analyze received comments and determine the negative sentiment value of the received comments. If the sentiment of received comments is above a threshold value, profile module210may associate an increased risk with that profile. Generated profiles and associated risk may be communicated to risk module220.

Risk module220operates generally to receive risk profiles and determine a risk value for receive risk profiles. For example, risk values may be low, medium, or high. Risk values may increase the efficiency of monitoring software components, as developers may focus on components with higher risk values. Risk module220may receive a risk profile generated by profile module210. In various embodiments, risk module220may determine a risk value of high, medium, or low for each received risk profile. The risk value determination may be based on separate predetermined thresholds of risk associated with each risk value or level. A high risk value may have a relativity higher associated risk threshold than a medium risk value, which may have a relatively higher associated risk threshold than a low risk value. Determined risk values and received risk profiles may be indexed and stored in memory or communicated to monitoring module230.

Monitoring module230operates generally to receive risk profiles and associated risk values, monitor components associated with received risk profiles, and update risk profile values. For example, monitoring module230may receive a risk profile with a risk value of “high.” For the associated component of the high risk profile, monitoring module230may communicate with testing device150to set the log collection to “fine.” Fine log collection may collect every instance of the component, for example, when traces are run, debugging is performed, configurations are changed, information is added, or warning, error and fatal messages are generated. Monitoring module230may set log collection to be “aggressive.” Aggressive log collection may be a short periodic collection, for example, every 2 minutes, or in various embodiments, continuous collection. It should be appreciated that the time frame of collection described above is exemplary and should not be interpreted as limiting. Monitoring module230may communicate to developer device130to set metric collection to aggressive. Aggressive metric collection may include data collection of all attributes of the component as well as all vertically dependent components, for example, dependent middleware, operating systems, etc. The time frame for metric collection may be set as aggressive as well, for example 5 minute intervals, or continuous collection. These aggressive settings set by monitoring module230may increase the attention a component received from a developer and warning messages and failure notifications may be generated at an increased frequency by, for example, testing device150based on failure logs or other data.

In various embodiments, monitoring module230may receive a risk profile with a medium associated risk value. For a medium risk value, monitoring module230may communicate a log collection setting, as described above, to “informational.” An informational log collection may, for example, only collect warning, error, and fatal messages. The interval for collection may be set as “normal.” In various embodiments, a normal collection setting may be any time interval longer than an aggressive time interval, for example, every 5 minutes. Monitoring module230may communicate to developer device130to set metric collection to normal. In various embodiments, normal metric collection may be only the collection of a predetermined subset of metrics of the metrics capable of being monitored. Monitoring module230may set a metric collection interval of normal, where a normal collection interval is longer than an aggressive collection interval, for example every 10 minutes.

In various embodiments, monitoring module230may receive a risk profile with a low associated risk value. For a low risk value, monitoring module230may communicate a log collection setting, as described above, to be set as “warning”, where, for example, only fatal messages are collected. The interval for log collection may be on demand or manual, where no periodic collection is performed, or a time interval longer than normal, for example every 10 minutes. Monitoring module230may communicate to developer device130to set metric collection to “minimal.” In various embodiments, minimal metric collection may only be a selection from the subset of metrics used in normal metric collection. The interval for metric collection may be on demand or manual, where no periodic collection is performed, or a time interval longer than normal, for example every 15 minutes.

Monitoring module230may periodically query developer device130, testing device150, and field device170for updates or changes in data, receive new data from various devices and update the risk value of received profiles. A change in the risk value of a risk profile may change the log collection, metric collection, and associated collection intervals to match the new risk value of the risk profile.

Referring toFIG. 3, a method300depicts the operational steps of server application120, on server110within the data processing environment. Referring now toFIGS. 1, 2, and 3, in step305, receiving module200receives software data artifacts, or a plurality or data, via sever application120. Software data artifacts may include component-code dependency graph data, code change data, component data, failure histories or logs, incident data, and/or social media comments. Receiving module200may receive a subsequent set of data with changes relative to the first set and determine and index changes in received data, in step310. Receiving module200communicated received data to profile module210and profile module210generates risk profiles based on the received data, in step320, as described above. In various embodiments, a component code graph is generated, in step330, based on the component and code data received by receiving module200. The component code graph may contain nodes based on the software modules or components in which data was received and directional vertices based on an amount of code value that represents the strength of the components dependency on the code. In various embodiments the component code graph may be an undirected tree graph.

Profile module210communicates generated risk profiles and/or the generated component code graph to risk module220and risk module220assigns a risk value to each received risk profile based on the associated communicated data, in step340, as descried above. Risk module220communicates risk profiles with assigned risk values and received data to monitoring module230and monitoring module230analyzes the received data, in step350, and communicated settings to developer device130, testing device150, and field device170associated with the risk level, as described above.

Monitoring module230modifies the assigned risk value, in step360, in response to receiving additional data from developer device130, testing device150, and field device170. Monitoring module230periodically queries or monitors developer device130, testing device150, and field device170for changes in the received data, in step370. Monitoring module230records and changes determined in the received data, in step380, and in response, modifies the assigned risk value associated with the risk profile in which there was recorded changed data, in step390. In various embodiments, monitoring module230may continue to periodically query for changes in received data and continuously modify the risk value associated with received risk profiles generated by profile module210. This continuous modification may enable developers to take advantage of the dynamic risk values to focus on one component or another based on the risk value of the associated risk profile of that component.

Referring toFIG. 4, a block diagram of components of a computing device of distributed data processing environment100ofFIG. 1is depicted, for example, server110, in accordance with an embodiment of the present invention. It should be appreciated thatFIG. 4provides only an illustration of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

Server110may include one or more processors402, one or more computer-readable RAMs404, one or more computer-readable ROMs406, one or more computer readable storage media408, device drivers412, read/write drive or interface414, network adapter or interface416, all interconnected over a communications fabric418. Communications fabric418may be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system.

One or more operating systems410, and one or more application programs411, for example, server application120, are stored on one or more of the computer readable storage media408for execution by one or more of the processors402via one or more of the respective RAMs404(which typically include cache memory). In the illustrated embodiment, each of the computer readable storage media408may be a magnetic disk storage device of an internal hard drive, CD-ROM, DVD, memory stick, magnetic tape, magnetic disk, optical disk, a semiconductor storage device such as RAM, ROM, EPROM, flash memory or any other computer-readable tangible storage device that can store a computer program and digital information.

Server110may also include a R/W drive or interface414to read from and write to one or more portable computer readable storage media426. Application programs411on server110may be stored on one or more of the portable computer readable storage media426, read via the respective R/W drive or interface414and loaded into the respective computer readable storage media408.

Server110may also include a display screen420, a keyboard or keypad422, and a computer mouse or touchpad424. Device drivers412interface to display screen420for imaging, to keyboard or keypad422, to computer mouse or touchpad424, and/or to display screen420for pressure sensing of alphanumeric character entry and user selections. The device drivers412, R/W drive or interface414and network adapter or interface416may comprise hardware and software (stored on computer readable storage media408and/or ROM406).

Referring now toFIG. 5, an illustrative cloud computing environment500is depicted. As shown, cloud computing environment500comprises one or more cloud computing nodes510with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone540A, desktop computer540B, laptop computer540C, and/or automobile computer system540N may communicate. Computing nodes510may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment500to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices540A-N shown inFIG. 5are intended to be illustrative only and that computing nodes510and cloud computing environment500can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Hardware and software layer600includes hardware and software components. Examples of hardware components include: mainframes601; RISC (Reduced Instruction Set Computer) architecture based servers602; servers603; blade servers604; storage devices605; and networks and networking components606. In some embodiments, software components include network application server software607and database software608.

Virtualization layer670provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers671; virtual storage672; virtual networks673, including virtual private networks; virtual applications and operating systems674; and virtual clients675.

Workloads layer690provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation691; software development and lifecycle management692; virtual classroom education delivery693; data analytics processing694; transaction processing695; and risk management processing696.