Abstract: Systems and methods for creating and deploying jobs in a cloud-based service include receiving a job definition defining job attributes pertaining to a job to be deployed in a cloud-based service. The job definition is processed to determine whether the job definition complies with predefined rules for job creation in the cloud-based service. Based on the determination of whether the job definition complies with the predefined rules for job creation in the cloud-based server, the job may be validated or not validated in the cloud-based service. Deployment policies are determined for validated jobs based on the job definition for the validated job.

Abstract: Systems and methods for automatically recovering from software regression in a cloud computing environment. One example method includes determining, with an electronic processor, that a batch software update has been applied to the cloud computing environment. The method includes, in response to determining that a batch software update has been applied, transmitting a problem request to an event listener server. The method includes receiving, from the event listener server, a problem statement including a stack trace. The method includes determining, based on the stack trace, a software feature indicator. The method includes transmitting the software feature indicator to a root cause analyzer. The method includes receiving, from the root cause analyzer, a change list indicator and a relevancy score associated with the change list indicator. The method includes performing a mitigation action based on the change list indicator when the relevancy score exceeds a relevancy threshold.

Abstract: A method of and system for selecting users for a rollout process of a feature is carried out by receiving an indication of the rollout process for the feature being rolled out, accessing a rollout plan, the rollout plan including a plurality of stages for the rollout process, and selecting users from a user population for each of the plurality of stages of the rollout process. Selecting the users from a user population includes examining a property to determine if a user in the user population is indicated as opted into being a late-stage receiver, and upon determining that the user is opted into being the late-stage receiver, excluding the user from the user population for one or more early stages of the rollout and including the user into the user population in one or more late stages of the rollout process.

Abstract: A method of and system for selecting users for a rollout process of a feature is carried out by receiving an indication of the rollout process for the feature being rolled out, accessing a rollout plan, the rollout plan including a plurality of stages for the rollout process, and selecting users from a user population for each of the plurality of stages of the rollout process. Selecting the users from a user population includes examining a property to determine if a user in the user population is indicated as opted into being a late-stage receiver, and upon determining that the user is opted into being the late-stage receiver, excluding the user from the user population for one or more early stages of the rollout and including the user into the user population in one or more late stages of the rollout process.

Abstract: Systems and methods for automatically reducing regression for a software payload applied to a plurality of computing platforms by a software updater. One example method includes receiving a health request associated with the payload, and retrieving, from an escalation engine, a plurality of identifiers identifying a subset of the plurality of computing platforms that have completed deployment of the payload, and determining a plurality of ULS tags associated with the payload. The method includes querying an anomaly detector for failure data, including pre and post-deployment data, for the subset corresponding to the ULS tags, detecting a potential software regression associated with the payload by comparing the pre and post-deployment data, and querying a root cause analyzer based on the potential regression. The method includes receiving an identifier identifying a potential root cause for the potential regression, and transmitting an event based on the potential regression and the potential root cause.

Abstract: Systems and methods relate to determining whether a particular failure of a web page feature is related to a recently implemented modification, and, when applicable, automatically taking one or more actions to return the web page to a functioning state (revert the modification). One embodiment provides a system for web page recovery. The system includes at least one server including an electronic processor and memory. The memory stores instructions that, when executed by the electronic processor, cause the system to obtain a web page log, detect a failure of a feature of a web page related to the web page log, identify one or more change packages related to the web page, determine a set of possible root causes for the failure of the feature based on the one or more change packages, select one possible root cause, and revert the one possible root cause.

Abstract: A system enables initiation of request driven peak-hour builds to override “off-peak” patching schedules for updating server applications. An “off-peak” patching schedule is generated to minimize disruption from installing builds of patches. Notwithstanding the “off-peak” patching schedule, a tenant administrator initiates request driven peak-hour builds when some performance failure occurs during peak business hours. For example, the tenant administrator may generate a service request that includes incident data that is usable to identify and/or develop a particular patch for resolving the performance failure. Based on the service request, the “off-peak” patching schedule is overridden to expedite an out-of-sequence installation of a particular patch. In this way, a tenant administrator that becomes aware that some performance failure is disrupting information workers during a peak usage time-range (e.g.

Abstract: Systems and methods for automatically reducing regression for a software payload applied to a plurality of computing platforms by a software updater. One example method includes receiving a health request associated with the payload, and retrieving, from an escalation engine, a plurality of identifiers identifying a subset of the plurality of computing platforms that have completed deployment of the payload, and determining a plurality of ULS tags associated with the payload. The method includes querying an anomaly detector for failure data, including pre and post-deployment data, for the subset corresponding to the ULS tags, detecting a potential software regression associated with the payload by comparing the pre and post-deployment data, and querying a root cause analyzer based on the potential regression. The method includes receiving an identifier identifying a potential root cause for the potential regression, and transmitting an event based on the potential regression and the potential root cause.

Abstract: Systems and methods relate to determining whether a particular failure of a web page feature is related to a recently implemented modification, and, when applicable, automatically taking one or more actions to return the web page to a functioning state (revert the modification). One embodiment provides a system for web page recovery. The system includes at least one server including an electronic processor and memory. The memory stores instructions that, when executed by the electronic processor, cause the system to obtain a web page log, detect a failure of a feature of a web page related to the web page log, identify one or more change packages related to the web page, determine a set of possible root causes for the failure of the feature based on the one or more change packages, select one possible root cause, and revert the one possible root cause.

Abstract: Systems and methods for automatically recovering from software regression in a cloud computing environment. One example method includes determining, with an electronic processor, that a batch software update has been applied to the cloud computing environment. The method includes, in response to determining that a batch software update has been applied, transmitting a problem request to an event listener server. The method includes receiving, from the event listener server, a problem statement including a stack trace. The method includes determining, based on the stack trace, a software feature indicator. The method includes transmitting the software feature indicator to a root cause analyzer. The method includes receiving, from the root cause analyzer, a change list indicator and a relevancy score associated with the change list indicator. The method includes performing a mitigation action based on the change list indicator when the relevancy score exceeds a relevancy threshold.

Abstract: A system to reduce strain on server farm computing resources by over-riding “off-peak” patching schedules in response to performance failures occurring on a server farm. Embodiments disclosed herein determine a patching schedule for causing builds of patches to be sequentially installed on server farms during an off-peak usage time-range. Responsive to a performance failure occurring on the server farm, embodiments disclosed herein identify a particular patch that is designed to resolve the performance failure. Then, the patching schedule is over-ridden to expedite an out-of-sequence installation of whichever build is first to include the particular patch. Because resolution of the performance failure is expedited, the impact of the performance failure on the computing resources of the server farm is reduced as compared to existing server farm patching systems.

Abstract: A system enables initiation of request driven peak-hour builds to override “off-peak” patching schedules for updating server applications. An “off-peak” patching schedule is generated to minimize disruption from installing builds of patches. Notwithstanding the “off-peak” patching schedule, a tenant administrator initiates request driven peak-hour builds when some performance failure occurs during peak business hours. For example, the tenant administrator may generate a service request that includes incident data that is usable to identify and/or develop a particular patch for resolving the performance failure. Based on the service request, the “off-peak” patching schedule is overridden to expedite an out-of-sequence installation of a particular patch. In this way, a tenant administrator that becomes aware that some performance failure is disrupting information workers during a peak usage time-range (e.g.

Abstract: A system enables initiation of request driven peak-hour builds to override “off-peak” patching schedules for updating server applications. An “off-peak” patching schedule is generated to minimize disruption from installing builds of patches. Notwithstanding the “off-peak” patching schedule, a tenant administrator initiates request driven peak-hour builds when some performance failure occurs during peak business hours. For example, the tenant administrator may generate a service request that includes incident data that is usable to identify and/or develop a particular patch for resolving the performance failure. Based on the service request, the “off-peak” patching schedule is overridden to expedite an out-of-sequence installation of a particular patch. In this way, a tenant administrator that becomes aware that some performance failure is disrupting information workers during a peak usage time-range (e.g.

Abstract: A system to reduce strain on server farm computing resources by over-riding “off-peak” patching schedules in response to performance failures occurring on a server farm. Embodiments disclosed herein determine a patching schedule for causing builds of patches to be sequentially installed on server farms during an off-peak usage time-range. Responsive to a performance failure occurring on the server farm, embodiments disclosed herein identify a particular patch that is designed to resolve the performance failure. Then, the patching schedule is over-ridden to expedite an out-of-sequence installation of whichever build is first to include the particular patch. Because resolution of the performance failure is expedited, the impact of the performance failure on the computing resources of the server farm is reduced as compared to existing server farm patching systems.

Abstract: A system enables initiation of request driven peak-hour builds to override “off-peak” patching schedules for updating server applications. An “off-peak” patching schedule is generated to minimize disruption from installing builds of patches. Notwithstanding the “off-peak” patching schedule, a tenant administrator initiates request driven peak-hour builds when some performance failure occurs during peak business hours. For example, the tenant administrator may generate a service request that includes incident data that is usable to identify and/or develop a particular patch for resolving the performance failure. Based on the service request, the “off-peak” patching schedule is overridden to expedite an out-of-sequence installation of a particular patch. In this way, a tenant administrator that becomes aware that some performance failure is disrupting information workers during a peak usage time-range (e.g.

Abstract: A system to reduce strain on server farm computing resources by over-riding “off-peak” patching schedules in response to performance failures occurring on a server farm. Embodiments disclosed herein determine a patching schedule for causing builds of patches to be sequentially installed on server farms during an off-peak usage time-range. Responsive to a performance failure occurring on the server farm, embodiments disclosed herein identify a particular patch that is designed to resolve the performance failure. Then, the patching schedule is over-ridden to expedite an out-of-sequence installation of whichever build is first to include the particular patch. Because resolution of the performance failure is expedited, the impact of the performance failure on the computing resources of the server farm is reduced as compared to existing server farm patching systems.