PEGA Deployment Manager - A product that is in dire need of reverse thinking / reverse engineering.

Background:

In the modern CI CD era, PEGA Deployment Manager (PDM) is a product that is developed by PEGA for its customers to

  • Create and Manage Pipelines with stages and steps
  • Perform Guardrail Compliance checks
  • Run Unit Testing Checks
  • Publishes artifacts to a repository
  • Branching / Merging operations
  • Deploys to a higher environment all the way to production environment and at times perhaps manage rollbacks in the event of failure.
  • Integration with Jenkins to manage jobs that cannot be natively managed by PEGA, and
  • A few more additional capabilities like approvals / rejections, notifications etc

It certainly looks fancy but why does it need reverse thinking?

From the outside, it does feel like it almost covers all the checklist items that one would need to implement a CI CD pipeline, but the real question is :

Is PEGA really the right platform to create deployment Manager product?

Now, that makes us ponder about what are the limitations of Pega Deployment Manager?

Here are some key limitations :

  • Inability to support a variety of testing tools available in the market or at-least offer a runtime environment to enable set up : For example, a client may prefer to use selenium , or node js or may be a tool that's recently in the market and offers just what they want. PDM neither support these tools natively nor does it have the capability to set up an runtime environment.
  • Lack of contribution from worldwide developer community due to its strictly locked down mode: Since PEGA is more of reserved / locked down product, and that completely takes contribution from a wider range of open-source developer communities out of equation.
  • Inability to create an ecosystem of its own like Azure Devops or Jenkins: For example, Azure Devops comes with Azure boards, ability to manage deployments and releases, repositories, artifacts storage etc., all at one place without having to switch user interfaces. We pretty much get a seamless user experience. In case of PEGA, the situation is entirely different. For instance, it offers agile studio and deployment manager as two distinct products and therefore a completely different end-user experience.

What might work?

Here are few ideas that I think might work in the long run when it comes to handling and managing products with PEGA

  • A strategically governed process around how to bring in worldwide developer community contributions - A Plugin Manager for PEGA: Perhaps if a plugin manger is available in PEGA that is similar to that of Jenkins or Azure Devops Marketplace extension and allows dev community to contribute through a governed process, then it would make it a lot more open for wider developer communities involvement.
  • Bringing a lot more Creativity onto the table (Thinking outside the box): Let's be honest, while Pega hackathons are great but I really wish they could get a lot more creative and interesting by not limiting the developer's ideologies solely to PEGA platform. Besides, I reckon it may be also worthwhile to accept at times that, not all could be automated with PEGA.
  • Creating an easier and optimised user experience for different products in PEGA: It would be nicer to transition between multiple products developed by PEGA with ease, for instance like a bluetooth multipoint that allows us to switch between multiple devices seamlessly. This enriches user experience to a whole new level.
  • Perhaps, create a plugin in Jenkins or an extension in Azure Devops or a package in node package manager (npm) or other popular tools in the market: It sort of provides a easy way to simply configure / install the plugin or extension and bingo, it completely makes it a lot easier by making PEGA a lot more open and thereby offering seamless integration with other platforms rather than it being vice-versa.

Disclaimer: This article is completely based out of my perception and opinions might differ from person to person. The objective of this article is to highlight what could be better and if there could be an easy way for worldwide developer community to contribute.

Pratik Desai

Pega Architect. 3x Pega Certified

2 年

Greate analysis and pointers..

Ravikiran C

Digital Automation | Pega Lead System Architect - CLSA

2 年

Agreed . There are improvement areas for DM. However, we can use the existing one as is within Pure Pega ecosystem

Bukhari Saheb Shaik

Pega Architect @ Victoria Govt, Australia

2 年

Bhuvaneshwaran Srinivasan interesting article. While PDM isn’t a typical Devops tool, all the functions mentioned in the article can be implemented as it’s still Pega under the hood. Also, it’s not really practical to support all the automation tools natively by products. Hence the API can be leveraged to achieve that functionality. It’s a bit of effort, but achievable. However, PDM NOT being a commercial product/offering in pega suite, I guess it should be take a good starting point and not a one stop solution for devops process

Ricardo Francisco

DevOps Engineering Manager

2 年

I wonder if they got it... Good article!

要查看或添加评论,请登录

Bhuvaneshwaran Srinivasan的更多文章

社区洞察

其他会员也浏览了