Artifacts and repositories
Can I use Deployment Manager without hosting an artifact repository?
Deployment Manager requires the use of a repository manager to publish and store application artifacts (product rule archives). This workflow provides a stable and reliable access to repositories, supports a large number of common binaries across different environments, and provides a higher level of security and access control for your application.
Why are there two repositories being used in the pipeline?
There 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 is a clear way to know what is the output from the different stages in the pipelines
- Development repository - This contains the output from the development environment as part of the Generating artifact task. It will also have a folder named Branches that contains archives of the all the branches that were merged as part of the pipeline (starting in version 4.4).
- Production repository - This holds 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 that you can trust that all archives in a production repository have passed necessary validation, reducing the possibility for buggy or unstable versions in production.
Are custom repository types supported?
Yes, you can build custom repositories starting 7.4. See Creating and using custom repository types for Deployment Manager for more information.
Can I use GitHub / GitLab / Bitbucket / SVN or other Source Code Manager (SCM) tools as a repository with Deployment Manager?
Github, BitBucket, SVN and other SCM tools are not compatible as a repository for Deployment Manager to deploy Pega applications.
- After exporting the application archive (zip file) that contains the deployable application, store the artifact using an artifact repository such as S3, JFrog Artifactory, or the file system.
Is the Pega repository type supported?
No, Deployment Manager does not support using the Pega repository type to store application artifacts as part of the pipeline deployment. The Pega repository type currently is only supported the Rebase feature in the platform, and in the future the Rebase feature is also likely to move away from the use of the Pega repository. There are a few reasons why Pega repository should not be used:
- The Pega repository stores all the artifacts in the Pega node temporary folder. Each node has its own temporary folder or working directory to store various caches or other session specific data. This node workspace is not guaranteed to be persistent and can easily be wiped out on restart or when the caches are cleared.
- Pega repository only works for single node deployments, where there is only one working directory involved. Multi node deployments could end up in a situation where each time a requestor is authenticated it could be in a different node and thus the artifacts published will not be visible.
- Lastly, it is the practice at most companies that lower environments are not allowed to connect directly to higher environments as a general SecOps workflow. Using a Pega repository will force that a Pega environment (likely) a lower one will have access to higher environment breaking this policy.
Is the defaultstore repository supported?
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.
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. See Creating pipelines for referencing repositories in the pipeline as part of the help for additional information.
How are artifacts generated over the course of a deployment?
Deployment Manager follows the DevOps industry best practices. 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 development environment, and then published to the development repository. Higher environments such as Quality Assurance and Staging will obtain the same package from development repository.
If the publish to production task is used at the end of a stage (Staging environment template offers this provision out of box), then after all tasks are successfully completed, the same package is promoted (copied over) to the production repository and is deployed to a production environment. This ensures that only fully validated application product archives are available to be deployed to production.
Previous topic Pipeline modeling Next topic Continuous integration and merging branches