So I've got my deploy working on a build and I've set up my build to create a deployment package and execute the package on the target server. Great so far.
Now however the application is expanding and I need to have different configurations per machine (account names and such like),
Can I specify what the file name of "setParameters.xml" for example to "Server1.SetParameters.xml" or similar ?
I've got it copying the files over the SetParameters.xml before each deploy for now but is seems in-elegant and should a file get locked for what ever the reason it would deploy the wrong settings to the wrong server.
Since you are using the WPP-generated deploy.cmd file, the simplest choice is to set %_DeploySetParametersFile% to a full path to your setParmeters file before you execute the deploy script.
SET _DeploySetParametersFile=c:\full\path\to\setParmaeters.xml
call Website.deploy.cmd
Alternatively, if you want to use msdeploy directly, you can specify -setParamFile:c:\full\path\to\setParmaeters.xml. For more information, see Web Deploy Operation Settings
Related
Using Azure Build Pipelines i'm trying to publish an ASP.NET WebForms website to IIS.
Everything works, except that I have several images in a folder of my website (e.g. /Images/1.jpg,2.jpg, etc..) and I would like to delete all images from that folder except 2.jpg and rename it to 1.jpg after I've deployed the website (or during the release pipeline if that's possible)
Is there any way to do this in Azure Pipelines?
Here you can take a look at a Catalog of the built-in tasks for build-release.
The Delete Files task states:
"Use this task in a build or release pipeline to delete files or folders from the agent working directory".
This may give you some ideas on how to achieve this.
I hope this help.
Comment on:
The Delete Files task states: "Use this task in a build or release pipeline to delete files or folders from the agent working directory".
and
".. from what I just tried, this can only delete files inside the artifact and not on the IIS Server."
That is correct for default behavior, but it has a parameter called SourceFolder, which has a default as "$(Build.SourcesDirectory)". When you specify the SourceFolder to be "C:" you can enter a pattern to delete anything on the server. Might be wiser to use a bit more elaborate path then just c:\ but it works. Just tried it on a pipeline where a file needed to be deleted not from the workingfolder but from the deployed IIS location.
PS in a release pipeline the default seems to be the $(System.DefaultWorkingDirectory) and not the $(Build.SourcesDirectory). Whether that is because the Build.SourcesDirectory defaults to System.DefaultWorkingDirectory in release pipelines or the task is being smart I don't know.
Can someone tell any way to deploy different web.config on different EC2 instances with in same deployment group.
Scenario: We have few entries in the config that will be different on different instances. So need some way to update based on instance.
Create a script to make the necessary changes to your web.config and then use the hooks section of your app.spec file to run the script before install on your deployment. https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html
I actually took the approach of storing my web.config files for each environment in an S3 bucket. As part of the CodeDeploy Deployment group process, it would download the config file from the S3 bucket in the After Install hook. This way you can build the application once and push the same application files for each environment. This also separates the configuration of the application from the actual code so that the development team doesn't need to know things like connection string values, etc...
I have a build definition set up on my TFS server. It builds happily but I can't figure out how to automate the process of having it copy the build to my development server.
I have a "Copy Files" task set up which works, but only when the source is this:
"C:\vsts-agent-win7-x64-2.103.1_work\8\s\ProjectName"
Obviously thats a hard-coded path and not great, so, is there an equivalent I could use to copy this build output to my development server?
Also, is there a way to have this happen over web deploy instead of file copy?
Thanks!
You can use the build variable $(Build.SourcesDirectory)\ProjectName, which should correspond to that folder. There is a link titled "Pre-defined variables" on the variables tab of your build definition that will show you other built-in variables.
I have 3 stages (dev / staging / production). I've successfully set up publishing for each, so that the code will be deployed, using msbuild, to the correct location, with the correct web configs transformed - all within Jenkins.
The problem I'm having is that I don't know to deploy the code to staging from what was built on dev (and staging to production). I'm currently using SVN as the source control, so I think I would need to somehow save the latest revision number dev has built and somehow tell Jenkins to build/deploy staging based on that number?
Is there a way to do this, or a better alternative?
Any help would be appreciated.
Edit: Decided to use the save the revision number method, which parses a file containing the revision number to the next job -- to do this, I followed this answer:
How to promote a specific build number from another job in Jenkins?
It explains how to copy an artifact from one job to another using the promotion plugin. For the artifact itself, I added a "Execute Windows batch command" build step after the main build with:
echo DEV_ENVIRONMENT_CORE_REVISION:%SVN_REVISION%>env.properties
Then in the staging job, using that above guide, copied that file, and then using a plugin EnvInject, to read from that file and set an environment variable, which can then be used as a parameter to the SVN Repository URL.
You should be able to identify the changeset number that was built in DEV and manually pass that changeset to the Jenkins build to pull that same changeset from SVN. Obviously that makes your deployment more manual. Maybe you can setup Jenkins to publish the changeset number to a file and then have the later env build to read that file for the changeset number.
We used to use this model as well and it was always complex. Eventually we moved to a build once and deploy many times model using WebDeploy. This has made the process much more simple. Check it out - http://www.dotnetcatch.com/2016/04/16/msbuild-once-msdeploy-many-times/
I am using MSBuild to Publish a web site, then copy the published site to a web server on the same network. I set the copy command to "SkipUnchangedFiles."
It works swimmingly, but Skip Unchanged won't work because when I use AspNetCompiler to publish the website, each and every file is "new" -- its date is set to the moment of publishing, so even if the contents of a given file have not changed, the timestamp is different, so it's copied over anyway.
Is there a workaround that will prevent file whose contents have not changed from being copied?
Depending on how you're publishing the site, you may be able to do Incremental Build instead of a full build.
There is no existing process for this as the deployment process isn't aware of the deployment target filesystem.
If you were aware you could do a diff using a tool like beyond compare and then grab only the binary diff'ed items and copy those across.
Looking to automate this you are probably going to have to dig into writing msbuild targets or post build scripts.