Automating Pipeline Deployment with Account Mapping
Hello, If you're looking to automate the deployment of pipelines from your Dev org to your Prod org—while dynamically switching out environment-specific accounts—this post might help. We ran into a challenge: many of our pipelines (some with 50+ accounts) needed to be deployed from Dev to Prod, but with different accounts in each environment. Unfortunately, SnapLogic doesn’t currently offer a native, out-of-the-box solution for replacing accounts during deployment. So, we built a workaround that works well for our use case. We developed a simple web interface to make selecting and deploying projects easier (optional), and we also back up deployed Prod projects and APIs to GitHub (also optional). The core idea, however, doesn’t rely on either of these extras. High-Level Overview The architecture is straightforward: A pipeline in the Dev org displays the available projects and APIs. A pipeline in the Prod org handles the actual deployment, replacing account references along the way. Let’s break down the approach. Pre-requisites Before this will work, four critical conditions must be met: Account Naming Convention Dev accounts: D[0-9][0-9][0-9]_anything (e.g., D001_SQLdb1_admin) Prod accounts: P[0-9][0-9][0-9]_anything_else (e.g., P001_SQLdb1_customer_admin) Each account pair must share a unique numeric prefix (e.g., 001). This prefix is used to map Dev accounts to their corresponding Prod equivalents. Accounts Stored in Root Shared Folder All environment-specific accounts should be stored in /shared/. This ensures that account paths remain consistent regardless of project space. Admin Access The service user executing these operations must have Org Admin rights in both Dev and Prod environments. Mirrored Project Spaces If a project is located in a specific project space in Dev, the exact same project space (same name) must exist in Prod. If all four conditions are satisfied, the process should work reliably. Exporting the Project (from Dev) In the Dev org, we use a pipeline to list available projects or APIs. Users select the item to deploy, and we pass its full path to the Prod pipeline. In the Prod org, we start by calling SnapLogic’s export API: https://docs.snaplogic.com/public-apis/get-project-export-project-path.html We issue a request to: https://{controlplane}/api/1/rest/public/project/export/{project_path}?asset_types=Pipeline&asset_types=Account&force=true This returns a ZIP archive containing: export.json: The pipeline definitions accounts_template.json: The referenced accounts in those pipelines Mapping Dev Accounts to Prod Accounts From accounts_template.json, we extract all Dev account references. For each one, we map it to its corresponding Prod account based on the naming convention: [ { "dev_account_id": "D037", "dev_account_path": "/YourOrg-Dev/shared/D037_something_CRM", "prod_account_id": "P037", "prod_account_path": "/YourOrg-Prod/shared/P037_something_different_CRM" }, ... ] Replacing Accounts in export.json A script (language-agnostic) processes export.json, replacing every instance of a Dev account path with its Prod equivalent. Since all accounts are stored in /shared/, the replacements are consistent across project spaces. This approach can be reversed as well—for example, when syncing from Prod back to Dev. Importing the Modified Project (to Prod) Finally, the updated export.json is zipped up and imported using SnapLogic’s import API: https://docs.snaplogic.com/public-apis/post-project-import-import-path.html Because we’re only modifying account paths, no credentials are exposed or transferred. Final Thoughts While SnapLogic doesn’t natively support environment-aware deployments, this solution fills the gap with automation and repeatability. Unfortunately, I can’t share the pipelines themselves, but with the above approach, you should be able to build a similar solution tailored to your environment. If you have any questions, feel free to ask. Thanks for reading!
