I'm pretty new to OctopusDeploy and am trying to set up a process to deploy our artifact to multiple Windows Servers.
As of right now it is deploying the package to the default working directory of C:\Octopus\Applications...... but I need it to be deployed to a different path.
I have defined a Custom Install Directory in the process editor, however this seems to be overlooked during the deployment, and the package just goes to the default directory.
I have tried substituting the path with a variable, but that didn't fix it. There are no errors or warnings in the deployment logs.
Can anyone help?
Sounds like you're taking the right steps to change your custom installation directory on your deployment.
One thing to check is that you've created a new release since updating your step configuration. Because releases in Octopus snapshot the deployment process, any updates you make won't show up in your deployments until you've created a new release.
Related
I have a Teamy City Build Server and wanted to migrate my solution piece by piece to Package Reference. Unfortunately it seems that it doesn't find the references / packages for those project I already moved or reacreated with package reference. The packages are restored correctly as I see them in the global .nuget\packages folder. Also I can build locally without any issues.
Funny enough, I have some other smaller projects which do work correctly with package reference on teamcity.
TeamCity Version: 2019.2
NuGet: 5.4
I also tried to add a .NET CLI Task with a restore command, but that didn't change anything aswell.
NuGet Installer Step:
dotnet restore step:
In the end I create a new pipeline and reconfigured all the steps from scratch instead of copy an existing pipline and now it works. seems there was some issue somewhere attached to those existing pipelines.
After an entire day of trying to fix this problem I finally found the cause.
In the parameters of the build configuration in TeamCity there was a parameter called "system.VisualStudioVersion" with its value set to "11.0". I changed the value to "16.0", and this fixed the problem for me.
This might explain the solution of NPadrutt, assuming he had the variable set in that particular build configuration. Recreating his build configuration would then result in a new build configuration without the bad parameter, fixing the problem for him. But in my situation the parameter was inherited from the root project, so recreating the build configuration wouldn't have fixed it for me.
I want to set up a small cucumber (maven) project in Jenkins in my company. The source code is local on my machine and not on any subversion system. I have already created a new job in jenkins. While configuring I am asked to give path to my pom.xml. But I dont know how do I give path.
Also I triggered Jenkins build without even configuring it properly, and therefore it has generated Workspace (Arbeitsbereich in german) for me. Now I think I just need to copy my source code to the created Workspace, but I dont know how do I do that exactly.
May be I am doing something really dumb here :( could someone please help ?
Jenkins default directory would be '~/.jenkins' where your jobs should be located. you can follow this link to use a custom directory as your work space.
After that, you can specify the path of your application pom.xml file relatively to your custom workspace location.
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 using a Capistrano deployment workflow for a Magento project.
On deploy Capistrano builds this Magento project on the server using https://github.com/Cotya/magento-composer-installer.
The issue is sometimes my Magento modules don't install correctly and I need to clear the cache, reindex or some other task to get everything 100%. The issues occur sporadically so I haven't been able to script a fix into the deployment process.
What I would like is on deploy Capistrano does not change the symlink to the new build straight away. Instead I am able to preview the site on another link, fix what needs to be fixed, then change the symlink manually.
Is this possible to set up using Capistrano?
If not, my other solution to this is to use the Magento maintenance flag however I would rather avoid having to put the site in maintenance. Open to other idea's as well!
Thanks
It is probably possible to do this by telling Capistrano to not include the symlink change as part of the process (something like Rake::Task["deploy:symlink:release"].clear_actions), and then running that manually (cap [env] deploy:symlink:release).
However, under the category of "Open to other ideas as well!" I'd suggest that you set up a staging site. Create a process to automatically restore a prod database back to stage, then deploy your code to stage and check it there. Once you have confirmed it works, deploy to prod and let the symlinks automatically do their job.