Context:
Currently we manually get a git dev branch built into a package into VSO, and once that package is built it deploys to Octopus and takes down the site for a good amount of time as all the built packages are loaded into each server the site sits on... But, honestly, a lot of the bug fixes end up being in js files that could easily just be hot swapped in... and it's just so annoying to have to wait for poor OPs and support to do all of this just for a teensy tiny change.
The pipedream:
I would like to set up CI that allows hot swapping of js,css,cshtml,html files to VSO and Octopus... This will allow small petty changes in javascript files to be issued out fast and without deployments...
...and also have another option that allows me to say, "look, i've changed some csharp files so i need a built package to be pushed up into VSO and Octopus". A manual rebuild if you will.
Question:
I'm missing the vocabulary to search for this in Google and wondered if you guys can help me on a path to setting this up.
You can just include the modified files (remain folder structure) in the package, then push this package to Octopus server and deploy with this package, then the necessary files will be replaced.
My workflow of IIS deploy:
New Deployment Target with Listening tentacle mode
Add Deploy to IIS process template for Octopus project
Enable Custom installation directory feature in Configure Features window of Process
Specify Custom Install Directory path in process
Build tasks:
Add Copy Files task to copy necessary files (e.g. js)
Add Package Application task to package these files (remain folder structure)
Add Push Packages to Octopus task
Add Create Octopus Release task
On the other hand, you can include all published files to package (tested with File System publish), then deploy with that package, the Octopus can compare files and just replace the modified files ({webapp}.dll will be replaced too, checked the Created, Modified time on target server)
Regarding get changed files during build, you can call Get commit with Changed items REST API, then create/modify the build variable (e.g. depAll) through Logging Command (e.g. PS: Write-Host "##vso[task.setvariable variable=depAll];]Yes") per to the changed files result, then using this variable in task condition (Control Options of each task) to determine which tasks need to be run. Specify conditions for running a task
Related
When a private agent build starts in VSTS, it gets assigned a directory, e.g. C:\vstsagent_work\1\s
Is there a way to set this to a different path? On other CI servers, like Jenkins, I can define a custom workspace for a job. I'm dealing with a huge monorepo and have dozens of build definitions around the same repository. It makes sense (to me anyway) to share a single directory on the build agent computer.
The benefit to me is that my builds can use pre-built components from upstream repositories, if they have already been built.
Thanks for any help
VSTS build always creates a working directory per build definition. This leaves you two options:
Create a single build definition and use conditionals on steps to skip certain steps in order to only run what is needed. This allows you to use the standard steps and may require a powershell script to figure out which steps to run and which ones to skip. Set variables from powershell using the special logging commands.
Disable the get sources step and add a step that manually fetches sources. You'll need to clean the working directory, checkout the right commit, basically replicating the actions in the get sources step manually. It may require some fidgeting to get all the behavior correctly for normal build, pull request builds etc. That way you can take full control over the location where sources are checked out.
I'd also recommend you investigate the 2017 project formats that use the new <packageReference> in the project files to fetch packages. The new system supports configuring a version range which can always fetch the latest available version of packages. It's a better long-term solution.
No, it isn’t available in VSTS build system.
You can change working directory of agent (C:\vstsagent_work) (Re-configure it and specify another working folder), but it won’t uses the same source folder for different build definitions, the folder would be 1, 2, 3 ….
I have a standard build configuration, ending with a simple ssh copy of the output files to a remote server.
The process wanted is simple:
The developper pushes the commit to production
Teamcity builds the product
The developper downloads the product from the remote server where build results are stored
The developper tests the product (end-to-end testing, testing setups etc, can't be automated at the moment).
If the product is okay, label the build that produced this output as the new version (let's say 3.2.1).
Teamcity applies the label, and moves the files produced by this build to a folder named after the label value (3.2.1 in this example).
Only the last step is missing, because I don't find any ways to connect on the tag action to trigger some sort of build action.
I already tried to link another build configuration to this one, but the issue is that it has to be triggered by the developper for a specific build ID, so the developper tests the output of a given build, if it's okay, he tells teamcity "Okay, release this build as version 3.2.1" and the build artifacts are persisted in a folder named 3_2_1 for instance.
During build msbuild creates deployment packages for several my web projects (and wcf services) which I want to run from command line (as last step of automated build process) to deploy to several different servers.
The structure of IIS application folders is the same on each one.
My problem is that I cannot find how to configure (override default value of IIS application). It is in .SetParameters.xml, like:
which is not what I want.
I read that it is possible to create parameters.xml in the project and put there something like:
or some say
I'm trying this but it does not change content of .SetParameters.xml
Can you advice what am I missing, or/and alternative way to do this.
Thanks!
If you want to deploy the web application package manually—either by running the .deploy.cmd file or by running MSDeploy.exe from the command line—there's nothing to stop you manually editing the SetParameters.xml file prior to the deployment. However, if you’re working on an enterprise-scale solution, you may need to deploy a web application package as part of a larger, automated build and deployment process. In this scenario, you need the Microsoft Build Engine (MSBuild) to modify the SetParameters.xml file for you. You can do this by using the MSBuild XmlPoke task.
For more information, please refer to: https://www.asp.net/web-forms/overview/deployment/web-deployment-in-the-enterprise/configuring-parameters-for-web-package-deployment
I've got an MVC 5 project stored in Git. I've installed TeamCity 9.1.7 (build 37573) on our build server and I've set it up to successfully perform a build when a developer checks in code to Git. My goal is to deploy the MVC application using MS Web Deploy if the build is successful. I've seen a number of tutorials that suggest using a web deploy package, but these tutorials are six or more years old. Is this still the preferred method for deploying a successful TeamCity build to IIS?
Further, we've added the web.config file to gitignore for a number of reasons. Git houses as Web.config.base that developers will copy to their own web.config file as a starting point. A developer will copy the web.config.base file to web.config when they first pull down the project. I've tried to set up a command line task in TeamCity to xcopy the web.config.base file to web.config
Working Directory: (left blank)
Command: xcopy MyMVCProject\Web.config.base MyMVCProject\Web.config
This build step fails with exit code 4 at all times. I've set the TeamCity build agent service to run as a local administrator. I've tried this as straight command text as above, as a cmd or bat file, and with a variety of different path styles, going so far as to use the TeamCity working directory variable, excluding the MyMVCProject from the path, including the MyMVCSolution in the path, etc. Any ideas as to why the xcopy would fail?
This is the same problem I was facing.
But at last, we put the master web.config file on the server where TeamCity is installed.
Then once the Project gets deployed , I replaced the web.config file with the web.config file which is alreay present on server.
So there will be no conflict in the web.cofig file
You just need to add one more build step after the Web deploy step.
In that you can use Xcopy and you can replaced you web.config file
Hope this will work
WebDeploy is still a great option for deploying ASP.NET web applications. Its even used with the brand new ASP.NET Core framework. We don't use TC but do you WebDeploy/MSDeploy extensively at work to deploy 50+ applications.
Regarding your config setup, I've never seen this approach. We use Parameterization to handle config changes per environment (local dev included). If you're worried about security of the config values, you could secure your SetParameter files which have the sensitive info and include the web.config in source control with default or placeholder values.
http://www.dotnetcatch.com/2014/09/08/parameterizationpreview-visual-studio-extension/
I am deploying a nuget package that comes to Octopus Deploy from TeamCity. What I need to do is to apply config transforms and deploy the zip archive of that package content (Windows Application binaries) to a specific folder of the tentacle. I even don't need to publish the package itself. Is there a way to achieve that?
If I understand you correctly, you should be able to achieve this fairly easily.
Have a standard step type of Deploy NuGet Package to install the nuget package onto the tentacle for the correct environment and role, ensuring that Configuration Variables and Xml Transforms are enabled - This will ensure your configs are transformed OOTB with no effort.
In order to then deploy the binaries I would use some custom powershell as this doesn't appear to be an "application type" that Octopus treats as a first class citizen. You could write the powershell inline as a second step by adding a step type of Run a PowerShell script and writing the code in the Octopus UI. Not knowing if the are going over a network share or any specifics I've not attempted to write any code.
My personal preference would be to write this as a powershell script that is included in the .nuget package. Octopus Deploy supports a naming convention on certain PowerShell files it finds in the .nuget package (PreDeploy.ps1, Deploy.ps1, PostDeploy.ps1). I'd write a PostDeploy.ps1 and package that up. I'd then have that script under source control and could easily make changes to it.
The caveat with this if you aren't careful is that you then start to move deployment implementations away from Octopus. However, written carefully and generically you could bootstrap the script with Variables (such as path to directory / network share etc) which makes it reusable should the need arise, and you can have it work differently in different environments.
Please pardon my ignorance if I've still not understood what you mean by the binaries "being in zipped form"
Further details on the Octopus Deploy PowerShell Scripts
Hope this help.
You could add a post-deployment powershell script to your deployment step to zip the contents of the deployment folder after the configs have been transformed.
https://blogs.technet.microsoft.com/heyscriptingguy/2015/03/09/use-powershell-to-create-zip-archive-of-folder/