Question
Last activity: 4 Sep 2015 5:23 EDT
Feature Toggling
We would like to merge everyday , this means committing code that doesn't break but isn't fully functional. Mostly in the UI. For example the code for a menu option should be there but the toggle will prevent it from being shown.
We would like ideas/tips/pointers on how to 'toggle' features in PRPC to make them inaccessible.
Anyone trying to doing something similar?
Thanks
Pegasystems Inc.
IN
Santanu - thanks a lot - you've given us options to explore. We'll report back either way.
Pegasystems Inc.
NL
I used Togglz for Java code at a previous company, which is nice.
For PRPC rules, could we use 'development' rulesets (how to easily turn on a feature?) or circumstancing based on application/operator/access group properties?
Yeah the options for feature toggling are more in the mainstream programming world - Java, Ruby - all got options. Haven't come across Togglz - so thanks for that one!
The team I'm working with are not sure the development rulesets is the thing but will look into it a little further - all these great tips BTW!
Pegasystems Inc.
NL
Thanks. Would be interested to hear what they think about circumstancing (use this rule if this condition, otherwise that rule). I've read about it, but never used it.
Pegasystems Inc.
IN
would enabling Approval required on ruleset version works?
also please refer for feature toggle-ness: Re: How can we put a boolean(ON OFF) button in a UI? Is there any OOTB control to do this in pega?
Thanks Phani.
Will explore teh Approval required on ruleset - and will report back.
The feature toggle-ness link is not applicable because what we are trying to do is put the code in the correct place - so the rule in the main 'branch' but have it functionally disabled. The link you sent was about a toggle 'control' in the app.
Hi,
You mean , you want to implement a " partial check in " kinda stuff in pega where your code will be committed but the feature will not be displayed to all ?
I think that is not possible to implement . The moment you commit your code ( in this case, check in your rule ) , it will be available for all to see and use the feature.
The best you can do is implementing " branching " in your application. When a development organization has two or more teams who are working on rules in the same application RuleSets, changes performed by one team might result in conflicts with changes performed by another team. These rule conflicts can become disruptive to the overall project, as resources must be spent to identify and resolve conflicts.By using branches, rule development can take place within an isolated space (the branch) without affecting functionality in the source rules.
Refer : http://pdn.pega.com/node/8920
You can also think of using extension points to customize the standard merge branch RuleSets process; for example, add behavior that enforces compliance with your organization's policies and procedures.
Refer : http://pdn.pega.com/node/11688