CI/CD DevOps with Azure
Microsoft’s Azure, a fast-growing and popular Iaas platform, lets you administer development operations such as managing pipelines for nightly releases, builds, integrations, software management, and data exchange between platforms stably.
PreRequisites
1)Salesforce CLI Ant App
The Ant App is what communicates metadata from Azure to other platforms like Salesforce, which is also what we’ll be demonstrating in later sections.
2)An Azure Trial Account
A minimal requirement for you to at least try your hand at integrations without committing to a subscription.
3)A Github Profile
You’ll host, as well as clone, standard repositories from here with XML source code in them.
4)A valid Salesforce Org
The target destination for possible Sales, Marketing, and Service data, as well as niche metadata from your Azure-deployed applications.
5)XML Files
Since you can’t code over Azure Directly, you’ll need these markup files to let Ant communicate to it.
Build.xml
This is what holds multiple platform(here Salesforce) user credentials and calls on package.xml.
Package.xml
Manipulates metadata and tells Ant which metadata to pick.
You could clone both these XML files and the Sample Metadata from the source code.
Setup Demonstration
Step1 – Initialize Azure
Login to Azure, spin up a new project, toggle between a preferred project ‘visibility’ setting(public or private) as depicted.
Step2 – Setup Repositories and Pipelines for Integration
Once files are created successfully, we’ll make changes to the pipeline to accommodate multiple Org credentials.
Press Build Pipeline on the top-right corner of the dialogue pane.
Then, go to Pipeline, and choose between starting afresh or using an existing pipeline.
Here, we pick Ant to configure and run a new YAML pipeline, which should bring up a .yml file.
We change the location next to Build to the path build/build.xml and Insert options as shown above to change credentials dynamically through a UI interface.
Modified the azure-pipelines.yml
We’re creating reference variables here to store values dynamically.
-Dsalesforce.loginurl=$(salesforce.loginurl) -Dsalesforce.password=$(salesforce.password) -Dsalesforce.username=$(salesforce.username) -Dsalesforce.testLevel=$(salesforce.testLevel)
Like : salesforce.loginurl, salesforce.password,salesforce.username,salesforce.testLevel
Add variables one by one and enter names of the values used in the YML file.
Next, enter the value of your Salesforce Org.
Keep passwords a secret.
Run Pipelines:
Click Save and Run near the top right of the page.
Then, you can see the progress status of your pipelines by clicking the Job.
From here, you can also track the changes you’ve made to your file.
Finally, we deploy!
Use-Cases
The idea in cases like these is to paint a picture of how you could ship and update relevant data points from a cloud-deployed service to Salesforce in real-time for insights and campaigns to drive value-driven decisions, project proposals, and discount offers.
Given time, you could auto-pilot data-entry and sync the two platforms to drive better usage from Salesforce. It also works for developers in institutions that need to backup data from Git, or simply prefer the DevOps environment to make code-changes to pipelines.
Benefits of Salesforce Azure DevOps Integration
You won’t need to make code-level changes to XML to switch between user profiles or Org every time you want to choose which Org to send metadata to. You could pull this off with even passable knowledge of integration systems.
Summary
In this demonstration, we looked at how metadata from Azure deployments like apps and service could be sent and repurposed for marketing, leads, other internal ops, and centralized backups in Salesforce.
For consultations on Iaas deployed services, scheduled metadata updates, and data repurposing strategies for CRM for your business, reach out to us at sales@hicglobalsolutions.com
