Method for enforcing change policy based on project state
First Claim
Patent Images
1. A method for enforcing change policies in a software development environment comprises:
- receiving at a source control system a request to make a change to a project;
defining a change management role and a policy to evaluate and allow or deny the change based on the defined change management rule and policy automatically and wherein the change management policy consists of a specified type of change that is being requested, a set of variables about the proposed change and a set of actions that is to be taken for each type of change and wherein the change management rule is defined based on the specified type of change, the set of variables and the set of actions, and wherein the specified type of change and the set of variables are captured from an user input or from a policy, user and group database, and wherein the change management policy is enforced automatically by mapping a physical source control system codelines to the project and by maintaining a state of the project with a user or group assigned to the project, and wherein the change management policy includes defining types of changes for triggering a rule, and wherein a release condition to which a particular project belongs is determined from a release management system, and a current state for a codeline is checked from a code review system to invoke an appropriate set of policies to accept or reject changes, when a change is submitted;
before making said changes, retrieving user information associated with a user requesting said changes, and determining a type of the requested change, and wherein said requested change is a first type of change or a second type of change, and wherein the first type of change and the second type of change are different types of changes from a set consisting of a codeline merge in the project, a codeline branch in the project, an addition of one or more features to a set of features that are specified in a data associated with the project, a downgrading or a deferral of one or more bugs in the project and a closing of bugs;
wherein, according to one or more policy rules, a first user is allowed to make the first type of change, and a second user is allowed to make the second type of change but not the first type of change;
based at least in part on the user information and the type of the requested change, evaluating the one or more policy rules to determine if the user is allowed to make the requested change; and
in response to evaluating the one or more policy rules, storing said requested change in the source control system when the user is allowed to make the requested change and rejecting said requested change when the user is not allowed to make the requested change; and
wherein the method is performed by one or more computing devices;
determining that the first requested change is to a first codeline within the project, when the requested change is a first requested change and a second requested change to a second codeline not within the project is also received, in the request, with the first requested change;
determining a first state of the first codeline and a second state of the second codeline, and wherein according to the one or more policy rules, the user is allowed to make changes to codelines in the first state but not to code lines codelines in the second state, wherein the second state is different than the first state;
wherein evaluating the one or more policy rules to determine if the user is allowed to make the first requested change is further based at least in part on the first state of the first codeline anddetermining if the user is allowed to make the second requested change based at least in part on the second state of the second codeline.
3 Assignments
0 Petitions
Accused Products
Abstract
A set of tools and other mechanisms automatically enforce software development change policies by providing a way to map physical source control system codelines to projects and by providing a way to maintain current project and codeline state information. The set of tools and other mechanisms also provide ways to define change management rules and policies, as well as, ways to evaluate and allow or deny each proposed change against the defined change policy.
-
Citations
16 Claims
-
1. A method for enforcing change policies in a software development environment comprises:
-
receiving at a source control system a request to make a change to a project;
defining a change management role and a policy to evaluate and allow or deny the change based on the defined change management rule and policy automatically and wherein the change management policy consists of a specified type of change that is being requested, a set of variables about the proposed change and a set of actions that is to be taken for each type of change and wherein the change management rule is defined based on the specified type of change, the set of variables and the set of actions, and wherein the specified type of change and the set of variables are captured from an user input or from a policy, user and group database, and wherein the change management policy is enforced automatically by mapping a physical source control system codelines to the project and by maintaining a state of the project with a user or group assigned to the project, and wherein the change management policy includes defining types of changes for triggering a rule, and wherein a release condition to which a particular project belongs is determined from a release management system, and a current state for a codeline is checked from a code review system to invoke an appropriate set of policies to accept or reject changes, when a change is submitted;before making said changes, retrieving user information associated with a user requesting said changes, and determining a type of the requested change, and wherein said requested change is a first type of change or a second type of change, and wherein the first type of change and the second type of change are different types of changes from a set consisting of a codeline merge in the project, a codeline branch in the project, an addition of one or more features to a set of features that are specified in a data associated with the project, a downgrading or a deferral of one or more bugs in the project and a closing of bugs; wherein, according to one or more policy rules, a first user is allowed to make the first type of change, and a second user is allowed to make the second type of change but not the first type of change; based at least in part on the user information and the type of the requested change, evaluating the one or more policy rules to determine if the user is allowed to make the requested change; and in response to evaluating the one or more policy rules, storing said requested change in the source control system when the user is allowed to make the requested change and rejecting said requested change when the user is not allowed to make the requested change; and
wherein the method is performed by one or more computing devices;determining that the first requested change is to a first codeline within the project, when the requested change is a first requested change and a second requested change to a second codeline not within the project is also received, in the request, with the first requested change; determining a first state of the first codeline and a second state of the second codeline, and wherein according to the one or more policy rules, the user is allowed to make changes to codelines in the first state but not to code lines codelines in the second state, wherein the second state is different than the first state; wherein evaluating the one or more policy rules to determine if the user is allowed to make the first requested change is further based at least in part on the first state of the first codeline and determining if the user is allowed to make the second requested change based at least in part on the second state of the second codeline. - View Dependent Claims (2, 4)
-
-
3. The method of claim wherein said project is a first project and wherein the requested change is a first requested change, further comprising:
-
maintaining a mapping between said first project and a first codeline of said first project, and between a second project and a second codeine of said second project; determining that the first requested change includes a first change to the first codeline of the first project, wherein a second requested change to a second codeline of the second project is received, in the request, with the first requested change; in response to the request, mapping the first codeline to said first project and the second codeline to said second project; and determining a first state for said first project and a second state for said second project; wherein, according to the one or more policy rules, the user is allowed to make changes to projects in the first state but not to projects in the second state, wherein the first state is different than the second state; wherein evaluating the one or more policy rules to determine if the user is allowed to make the first requested change is further based at least in part on the first state for said first project; and determining if the user is allowed to make the second requested change based at least in part on the second state of the second project.
-
-
5. A method comprising:
-
receiving at a source control system, a request to make a requested change to a project that is currently in a first state; before making said change; retrieving user information associated with a user requesting said requested change; accessing a stored mapping between states and policy rules, wherein the stored mapping maps the first state to a first set of one or more policy rules and a second state to a second set of one or more policy rules, wherein the second set is different from the first set; wherein, according to the first set of one or more policy rules, the user is allowed to make a particular change to the project when the project is in the first state; wherein, according to the second set of one or more policy rules, the user is not allowed to make the particular change to the project when the project is in the second state; based at least in part on the user information and the current state of the project, evaluating the first set of one or more policy rules to determine if the user is allowed to make the requested change; and in response to evaluating the first set of one or more policy rules; if the user is allowed to make the requested change, storing said requested change in the source control system, and if the user is not allowed to make the requested change, rejecting said requested change; receiving input that indicates the project is entering the second state, and, in response, automatically; causing the current state of the project to transition from the first state to the second state; and causing the policy rules that are evaluated to transition from the first set of policy to the second set of policy rules; wherein the method is performed by one or more computing devices, maintaining a stored mapping between the first project and a first codeline, and between a second project and a second codeline when the project is a first project, and wherein the request requests a first change to the first codeline and a second change to the second codeline; in response to the request, mapping the first codeline to said first project and the second codeline to the second project, and wherein the second project is in the second state when the first project is in the first state; evaluating the second set of one or more policy rules to determine if the user is allowed to make the second change; wherein, according to the first set of one or more policy rules, a first user is allowed to make one or more changes, and a second user is not allowed to make the one or more changes; determining whether the user is the first user or the second user; and
wherein evaluating the first set of one or more policy rules to determine if the user is allowed to make the requested change is further based at least in part on whether the user is the, first user or the second user. - View Dependent Claims (6, 7, 8)
-
-
9. A non-transitory computer-readable storage medium storing instructions for enforcing change policies in a software development:
- environment, the instructions including instructions which, when executed by one or more processors, cause the one or more processors to performs the steps of;
receiving at a source control system a request to make a change to a project; defining a change management rule and a policy to evaluate and allow or deny the change based on the defined change management rule and policy automatically and wherein the change;
management policy consists of a specified type of change that is being requested, a set of variables about the proposed change and a set of actions that is to be taken for each type of change and wherein the change management rule is defined based on the specified type of change, the set of variables and the set of actions and wherein the specified type of change and the set of variables are captured directly from the source control system or wherein, the;
specified type of change and the set of variables are captured from an user input or from a policy, user and group database and wherein change management policy is enforced automatically by mapping physical source control system codelines to projects and by maintaining a state of the project with a user or group assigned to the project and wherein the change management policy includes defining types of changes for triggering a rule;before making said change, retrieving user information associated with;
a user requesting said change, and determining a type of the requested change, and wherein said requested change is a first type of change or a second type of change, and wherein the first type of change and the second type of change are different types of changes from a;
set consisting of a codeline merge in the project, a codeline branch in the project, an addition of one or more features to a set of features that am sped tied in data associated with the project a downgrading or a deferral of one or more bugs in the project and a closing of bugs;wherein, according to the one or more policy rules, a first user is allowed to make the first type of change, and a second user is allowed to make the second type of change but not the first type of change; based at least in part on the user information and the type of the requested change, evaluating the one or more policy rules to determine if the user is allowed to make the requested change; and in response to evaluating the one or more policy rules; if the user is allowed to make the requested change, storing said change in the source control system, and if the user is not allowed to make the requested change, rejecting said requested change; wherein the requested change is a first requested change, and wherein the instructions, when executed by the one or more processors, further cause the one or more processors to perform; determining that the first requested change is to a first codeline within the project, and wherein a second requested change to a second codeline not within the project is received, in the request, with the first requested change; determining a first state of the first codeline and a second state of the second codeline; wherein, according to the one or more policy rules, the user is allowed to make changes to codelines in the first state but not to codelines in the second state, wherein the second state is different than the first state; wherein evaluating the one or more policy rules to determine if the user is allowed to make the first requested change is further based at least in part on the first state of the first codeline; and determining if the user is allowed to make the second requested change based at least in part on the second state of the second codeline. - View Dependent Claims (10, 11, 12)
- environment, the instructions including instructions which, when executed by one or more processors, cause the one or more processors to performs the steps of;
-
13. A non-transitory computer-readable storage medium storing instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of receiving, at a source control system, a request to make a requested change to a project that is currently in a first state;
-
before making said change; retrieving user information associated with a user requesting said requested change; accessing a stored mapping between states and policy rules, wherein the stored mapping maps the first state to a first set of one or more policy rules and a second state to a second set of one or more policy rules, wherein the second set is different from the first set; wherein according to the first set of one or more policy rules, the user is allowed to make a particular change to the project when the project is in the first state; wherein, according to the second set of one or more policy rules, the user is not allowed to make the particular change to the project when the project is in the second state; based at least in part on the user information and the current state of the project, evaluating the first set of one or more policy rules to determine if the user is allowed to make the requested change; and in response to evaluating the first set of one or more policy rules; if the user is allowed to make the requested change, storing said requested change in the source control system, and if the user is not allowed to make the requested change, rejecting said requested change; receiving input that indicates the project is entering the second state, and, in response, automatically; causing the current state of the project to transition from the first state to the second state; and causing the policy rules that are evaluated to transition from the first set of policy to the second set of policy rules; wherein the project is a first project, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to perform; maintaining a stored mapping between the first project and a first codeline, and between a second project and a second codeline; wherein the request requests a first change to the first codeline and a second change to the second codeline; in response to the request, mapping the first codeline to said first project and the second codeline to the second project; wherein the second project is in the second state when the first project is in the first state; evaluating the second set of one or more policy rules to determine if the user is allowed to make the second change. - View Dependent Claims (14, 15, 16)
-
Specification