Closed
Source control
I'd like to know how Pega teams integrate with source control systems such as Git or Subversion.
In particular, how do you manage release branches, hot fixes and merging?
This content is closed to future replies and is no longer being maintained or updated.
Links may no longer function. If you have a similar request, please write a new post.
I'd like to know how Pega teams integrate with source control systems such as Git or Subversion.
In particular, how do you manage release branches, hot fixes and merging?
Hello,
PRPC has the facilities already to handle version changes and hotfixes or maintenance levels (ML's) now. Plus merge facilities.
This PDN article might be of interest and get you pointed in the right direction.
Also the SSA 7.1 course has lesson and exercises on rulesets and merge facilities to handle parallel development.
Tara
Pega Academy Support Team
Hi Craig,
Like POTTT mentioned, Pega has it's own facilities to manage release rulesets, hot fixes etc.
Now a days, I'm seeing a few clients are trying to integrate this with other tools to achieve something of no use to Business. Some clients are trying to do "Deployment automation", I don't understand why would some one want to automate deployment and jeopardize their production systems.. It hardly takes 20 mins to do a deployment normally in Pega using Import (except for initial releases, then also most of the time is done for sanity testing).
Is that worthy to build custom solution for deployments? Absolutely no, it's just wasting resources on something which is already available and easily done in Pega. Pega is a BPM tool and shouldn't be used for IT projects where it's not intended to (can be used in IT projects where there's a process but definitely for things like Deployment automation etc.).
The point of automation is reliable repeatability across all environments, not just the final production release. Teams want to be able to promote a set of changes into, e.g., UAT, possibly making changes along the way. Each time, they want the changes to be pushed in a completely automated way. Once everything stabilises, they want to use exactly the same mechanism to push to production so they know they're getting exactly what they tested against in UAT.
Moreover, Pega is often not the only moving part in a complex environment. Being able to integrate Pega deployments into the larger ecosystem is hugely beneficial, allowing, for example, CI infrastructure to stand up the right version of a Pega application with a particular build of some downstream code base for automated testing with no human intervention.
Question Solved
Question
Question
Question
Question
Question
Question
Question
Question
Question
Pega Collaboration Center has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.