I have apex code stored in the master branch of my remote repository in GitHub and would like to deploy it directly into my Salesforce Org.
Is there a way to setup a "pipeline" in GitHub with Salesforce.com in order to facilitate a direct deployment into Salesforce?
Edited on 22nd-Oct-2022: is there a way to setup a button on GitHub that I can click on when I want to deploy changes (delta) from the master branch to a related Salesforce DEV Org?
Learn from Salesforce themselves. The https://github.com/trailheadapps/lwc-recipes (all lwc demos mentioned in documentation) contains actions to run code quality tools (prettier, lint), unit tests (apex, jest), deploy to scratch org, assign permission set, run all tests, delete the scratch org, report on code coverage...
Lots of goodies there. Might be too much if you're just after plain deploy to prod but it's good to know what toys are out there.
Related
I'm collaborating on a website using Github for source control. The site is hosted on a shared server on Dreamhost. I'd like to set up an easy way for myself and my collaborator to be able to see changes that have been merged into the main branch on the staging site then also run a couple of other shell commands (composer update, for example, after deploying the changes).
I'm new to this. I've found pieces of relevant documentation but have not been able to tie it all together. So far I am running into at least two issues.
Setting up github environments to point to development and staging environments
I looked into Github Workflows but it seemed Github Actions might be easier. I set up Github Environments called staging and development. When setting up the environments, I saw the option to add environment secrets but don't know what exactly to add here. So my environments in Github have names but don't really point to my development and staging environments. I think the first thing I need to figure out is how to link my Github Environments and actual development and staging environments together. I found Deploying with Github Actions but didn't find an answer there.
Invalid workflow file error
Also I found an action in Github Marketplace called branch-deploy. I created a yaml file under .github/workflows to test it. When this runs, I see an error on the workflow in Github of
Invalid workflow file
The workflow is not valid. .github/workflows/deploy.yml (Line: 2, Col: 1): Unexpected value 'id'
Not sure what is going on with this error because the "basic usage" example in the Marketplace page uses the same value for id.
I need help to understand better how to create complete CI/CD with Azure Devops for APim. Ok I already has explored the tools and read docs:
https://github.com/Azure/azure-api-management-devops-resource-kit
But I still have questions, my scenario:
APim dev instance with APi and operations created and others settings, as well APim prod instance created but empty.
I ran the extract tool and got the templates (not all), still need the Master (linked templates), and on this point seat my doubt, I already have 2 repos too(dev and prod).
How can I create the Master template, and how my changes from dev environment will be automatically applied to prod?
I didn't used the policyXMLBaseUrl parameters not sure what Path insert there, although seems #miaojiang inserted a folder from azure storage.
After some search and tries I deployed API's and Operations from an environment to another, but we still don't have a full automated scenario, where I make a change in a instance and that is automatically available.Is necessary to edit policies and definitions directly on the repositories or run the extract tool again.
I am new to VSTS. I am deploying Azure services using PowerShell using VSTS Release management. Now, On dev environment, everything goes well. I want to deploy to Clients Production Subscription. Client won't allow access to Production subscription to the dev team. In that Case, I have Cloned Dev environment pipeline and named it to Prod.
I am using the config file for each environment.
The client doesn't want to check-in Config file of Prod environment. My Question is How to populate Config file in Prod pipeline? First I thought of to copy Config file directly in Drop Folder ( in VSTS agent VM) but if Developer also has access to a private agent then the config is still in Developers' hand. We can't use multiple agents somehow.
Is there any specific way or VSTS security where we set some access permission?
Is there any location where we can put the file and use it in VSTS?
If somebody doesn't understand question Please ask me I will explain in detail.
We have a similar situation where Developers are not allowed to access prod. To solve the problem, we've created a Dev and Prod project. Developers setup the production project initially, but are denied access entirely now using Azure DevOps security groups. Only our Ops group has access to prod, including the repo that the config files are stored in.
To get things from Dev to Prod, we have a third project for our build engineering team that has scripts to promote artifacts from Dev to Prod. This team is neither Dev nor Ops and the promotion pipelines that we use to promote artifacts require approvals.
Looks like all you need is to create a new git repo and add the file that you would like to use. After that, just add the git repo in any release where you want to use it by adding a new artifact, selecting the git option under "Source type", and selecting the name of your repo in the "Source (repository)" dropdown.
You can use Secure files to manage the config file.
Using the portal:
Using the portal at https://manage.windowsazure.com/ this is easy. From a newly created azure web site:
Go to the dashboard
On the quick glance options on the right, click "Set up deployment from source control"
On the "where is your source code?" option, select Github
Authorize, then choose the repo name and branch.
BINGO: now pushes to that branch will trigger a deployment of that branch onto the azure website. Lovely.
Here's the problem:
I cannot for the life of me see how to do this from the command line (using the xpat-cli installed using npm: "npm install azure-cli -g")
It seems like I should be typing something like:
azure site deployment github --verbose --githubusername [username] --githubrepository [username/reponame] [sitename]
Because the help for "azure site deployment github" says it will: "Link a website to a github account for deployment"
Doesn't seem to work though...
If I then type:
azure site show [sitename]
The output says the source control is "LocalGit" instead of github - which is what it says if I do it the portal way above.
Source Control
data: --------------
data: Type: LocalGit
Any ideas?
Depending on your use case the solution will be different.
Assuming you have the same github source but want to deploy to multiple different Azure websites
Potential Solution: Make use of the Deploy to Azure Button See details here: https://azure.microsoft.com/blog/2014/11/13/deploy-to-azure-button-for-azure-websites-2/
Assuming you have various repositories that you want to deploy to Azure: Potential Solution: I am assuming that you will be the person deploying it. The workflow will be as follows:
A. Download files from Github to local folder See here
B. Publish your local folder into a new/existing Azure site. See here, or here. There are other github repositories to get some scripts right away
I understand this doesnt directly hook your system to do direct pull, but its one way to do it.
There is also:
http://www.imtraum.com/blog/streamline-git-with-powershell/
https://gallery.technet.microsoft.com/scriptcenter/a-GitHub-Repository-265c0b49
Both documents I found describing how to set up continuous deployment from GitHub say that you can configure the repo and branch with an Azure Resource Manager template, but you have to enter your credentials and complete the authorization process in the portal.
The script used in this tutorial will automatically configure
continuous publishing from your GitHub repository. This requires that
your GitHub credentials are already stored in Azure, otherwise the
scripted deployment will fail when attempting to configure source
control settings for the web apps.
To store your GitHub credentials in Azure, create a web app in the
Azure preview portal and configure GitHub deployment. You only need to
do this once.
I'd also suggest posting your xpat-cli problem as an issue on their GitHub repo.
Trying to make my life easier, Currently we have 4 developers working in Visual Studio 2012 and we are using TFS 2012 for source control. The project we work on is a multi-tenant web application (single source directory with multiple dbs) that is a mixture of legacy, asp and vb6 com components, coupled with new C# code. We use TFS for source control and for managing User Stories and Bugs. Because of the way our site works it can not be ran or debugged locally only on the server.
Source Control is currently setup with a separate branch for each developer that's working directory is mapped to a shared network path on the dev server that has a web site pointed to it in IIS. Dev01-Dev05 etc. The developers work on projects in their branch test it using their dev website, then check in changes to their own branch and merge those into the trunk. The trunk's work space is mapped to the main dev website so that the developers can test their changes against the other customer's dev domains to test against customizations and variances in functionality based on the specific dbs the are connected to.
Very long explanation but basically each dev has a branch and a site, that are then merged into the trunk with its own site.
In order to deploy our staging server:
I compile the trunk's website via a bat file on the server
Run a windows app I built to query TFS for changesets associated with
specific WorkItems in a certain status, and copy all the files for
those changesets from the publish folder to a deployment folder.
Run another bat file on the server to use RedGate's Deployment Manager
to create a package from those new files
Go to the DM site on our network to create and deploy that release (haven't been able to get the command line tools to work for this, so I have to do it manually)
Run any SQL scripts that have been saved off in Folders that match ticket numbers on each database (10 or so customer dbs) to support the release
I have tried using TFS automated build stuff and never really got it to build the website correctly. Played around with Cruise Control also with little success. Using a mishmash of skunk works projects to do this is very time consuming and unreliable at best.
My perfect scenario would be:
Gated Checkin, Attempt build/publish every time a developer merges into the trunk, rejects and notifies developer if the build fails.
End of the day collect the TFS Items of a certain status and deploys files associated with them to the staging site
Deploy SQL scripts for those TFS items across all the customer dbs in staging
Eventually* run automated regression UI tests, create new WorkItems or emails to devs if failed
Update TFS WorkItems to new state so QA/Customers know their items are ready to test in our staging environment
Send report of what items were deployed successfully
How can I get here so that I am not spending hours preparing and deploying releases to staging and eventually production? Pretty open to potential solutions, things that would be hard to change would be the source control we are using, can't really switch to subversion or something else so we are pretty stuck with TFS.
Thanks
Went back in and started trying to get TFS to build/publish my web solution. I was able to get a build to complete successfully. adding msbuild argument /p:DeployOnBuild=True and setting the msbuild platform to x86 seemed to do the trick on that.
Then I found https://github.com/red-gate/deployment-manager-tfs which gives you a build process template to do the package and deployment using the redgate tools. After playing with that for a bit I finally got it to create, package and deploy my build to our staging environment.
Next up will be to modify the template to run some custom scripts to collect only the correct items to deploy, deploy all the sql files and then to set the workitems to the appropriate statuses after completion.
Really detailed description of your process. Thanks for sharing!
I believe you can set up TFS to have gated check-in on a single branch, which if you can setup on trunk would make sure that the merges built successfully. That could trigger msbuild, if you can get that working or a custom build job.
If you can get that working then you'd be able to use that trunk code as the artifact to send to Deployment Manager. That avoids having to assemble the files for deployment through the TFS change sets, as you'd be confident that the trunk could always build.
Are you using Deployment Manager to deploy the database from source control as well as the application?
That could be a way to further automate the process. SQL Source Control and SQL CI allow you to source control the structure of a database, keep a database up to date on each check-in, and run database unit tests. They also produce database packages for Deployment Manager, so you can deploy a release that contains both the application and the database.
If you want to send me the command you're using in step 4 to deploy the release using Deployment Manager I can help out with that. The commands I use are:
DeploymentManager.exe --create-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1
DeploymentManager.exe --deploy-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1 --deployto=CI-Environment-Name
That will create a release version 1.1 using the latest available packages for that project. You can optionally specify the package to be used when creating the release with
--packageversion=<package name>=<version>
--packageversion="application=1.5