Repository related issues and queries in Deployment Manager
1. Why does Deployment Manager require the use of a repository manager?
Deployment Manager requires the use of a repository manager to publish and store application artifacts (product rule archives). There are a few reasons why having a dedicated application artifact repository manager is important.
Providing stable and reliable access to repositories
Repository tools such as JFrog Artifactory can be configured to be highly available
No single point of failure
Accommodate large load burts
Supporting a large number of common binaries across different environments
Scales with the number of binaries
Manages them across all the different environments without creating multiple copies
Security and access control
Implement a security policy that prevents un-validated applications from leaking out to production
Artifactory provides capabilities such as virtual repositories
Integration with LDAP, SAML etc
Complete logging - Tracing any action done to a file back to the user
Transferring a large number of binaries to a remote location
Managing infrastructure configuration across different environments
2. Why are there two repositories being used in the pipeline?
There really is no need for two different repository instances to be used, you can use the exact same repository for a pipeline. Deployment Manager will automatically create two folders, <repository location>/devops/dev and <repository location>/devops/prod which will be a clear way to know what is the output from the different stages in the pipelines
Development repository - This will contain the output from the Development environment as part of the Generating artifact task. It will also have a folder named Branches which will contain archives of the all the branches that were merged as part of the pipeline (starting in version 4.4)
Production repository - This will hold the archives that have made it through the pipeline and where the pipeline user or approver has manually approved through the Approve for production task. In this case the artifact associated with the deployment is fetched directly from the Development repository and copied over to the Production repository location
The reason to have this separate of development and production repositories (or folders if the same repository location is used) is to ensure that only approved and validated deployment archives are in the production repository. This gives you confidence for the following
You can trust that the archives in the production repository have passed all necessary validation as part of the pipelines, tests both automated and manual have been run, and it is safe to deploy to the production environment
Since there is only validation archives in production repository, if you have to roll back or redeploy from on an older version, all of those versions have been similarly validated
Deployment Manager will only deploy to production from the Production repository giving you confidence that intermediate and potentially buggy and unstable development versions do not make it into production. This is especially true if you lock down access to the production environment and you will only allow Deployment Manager to import new versions of the application.
3. Does Deployment Manager support custom repository types?
4. Can I use GitHub / GitLab / Bitbucket / SVN or other Source Code Manager (SCM) tools as a repository with Deployment Manager?
Ans: Github, BitBucket, SVN and other SCM tools do not makes sense as a repository for Deployment Manager deploying Pega applications.
If you are thinking of using an SCM tool as a version control for rules, that is simply not supported. Pega uses the layer cake concept and ruleset versioning (in the database) and rule resolution as the source control mechanism and that is what you have to rely on.
Once you export the application archive (zip file) that contains the deployable application, you should then use a artifact repository such as S3 or JFrog Artifactory or even the Filesystem to store the artifact.
This artifact is then used to publish to higher environments. All those repository types are supported by Pega, and other artifact management repository can be supported by following implementing the custom repository type as mentioned above.
The Releases feature of Github could be a possible solution, for which a custom repository implementation is needed, but the source control mechanism is not suited for Pega.
5. Does Deployment Manager support the use of the defaultstore repository?
No, the defaultstore represents the temporary folder associated with the Pega node. It is a system (platform) managed repository and should not be relied to store or persist artifacts. Many of the challenges associated with the use of the Pega repository also apply when using defaultstore.
6. What repository should I use on Pega Cloud?
If you have been provisioned Deployment Manager on Pega Cloud, you should use the pegacloudcustomerroot repository. This will be automatically configured for you and should not need to be specified in the pipeline. Please see the instructions for referencing repositories in the pipeline as part of the help for additional information.
7. How are artifacts generated over the course of a Deployment?
Deployment Manager follows the industry best practices DevOps, specifically the principle of Build Once, Deploy Many. In terms of Pega applications, there isn’t an explicit build step, however the application packaging process using the Product rule is the equivalent of the build step for code based projects. The product archive (package) is generated only on the dev environment, and then published to the Devrepository. Higher environments such as Quality Assurance and Staging will pick the same package from Development repository.
If the Production ready option is selected, then once all tasks are successfully completed, the same package is promoted (copied over) to the Prod repository and from there it’s deployed on Production environment. This will ensure that only fully validated application product archives are available to be deployed to production.
8. Authentication error while connecting to jfrog repository
Authentication profile given in the repository configuration should be valid.
Preemptive authentication need to be checked in authentication profile if it is a jfrog repository