I am currently doing an Octopus project using which I am trying to automate the below process,
Copy the installation files from the folder (TFS automatically drops the new builds to this place) to the octopus tentacle
Install and configure the application
Run the automated tests created using SOAP UI pro on the installed product
Send mail notifications to the user
Revert back the machine/Uninstalling the application
I have implemented all the above process using power shell in Octopus deploy. Only thing I am missing is the trigger process for project.
Requirement: Trigger the Octopus project containing above processes once a new build is created in TFS or new build is placed in the folder
There are two actions to "Trigger" Octopus Deploy to perform the steps defined in the project process, that can be initialised in a number of ways
Using the UI
1) Create a release
2) Deploy the release.
Using the API
1) Create a release and then instruct that release to be deployed to an environment (the important switch here is --deployto)
octo.exe create-release --server http://xxx --apikey SECRET --project xxx --version x.x.x --packageversion=x.x.x --deployto PRODUCTION
Note: this can also be done in two steps
Using Lifecycles
1) Create a release manually or using the API
2) Allow lifecycles to control what happens in environments when a release is created
Octopus Lifecycles Documentation
Hope this helps
You need to have the TFS build server upload newly built nuget packages to the Octopus Deploy server and create a Release post build.
https://octopus.com/blog/using-octopus-and-tfs-builds
Related
I'm trying to deploy a Angular application to my IIS server using Octopus and Azure DevOps
My application has multiple environments, each environment with it's own settings (config.prod.json)
What I want to do
Basically Octopus should take the release from Azure DevOps, and copy the release to multiple folders, with different config.prod.json files.
Each folder corresponds to a specific IIS website.
Azure DevOps pipeline setup
Use Node 14.x
npm install
ng build --prod
Archive dis/angular-app ; Archive type: zip
Publish Artifact; Path $(Build.ArtifactStagingDirectory)
Triggers : Enable continuous integration
Azure DevOps Releases setup
1. Package Application for Octopus
2. Push Package(s) to Octopus
3. Create Octopus Release
Octopus setup
One step DEPLOY TO IIS
1. Package details
2. Custom Installation Directory
[![enter image description here][5]][5]
3. IIS Web Site and Application Pool
Errors
In IIS while I click Binding, Basic settings, I get this error: There was an error while performing this operation. The parameter is incorrect
Also, the folder mapped in iis for the website that I'm targeting. Contains a folder drop with the zip file 27.zip (27 is the release id)
How do I unzip the zip file?
How do I replicate the zip file to the other environments?
Is my configuration ok so far? What am I doing wrong?
Just a few of the links that I've checked:
https://octopus.com/docs/guides/deploy-aspnetcore-app/to-iis/using-octopus-onprem-azure-devops-builtin
https://www.youtube.com/watch?v=NFqrWsUPCAM&t=345s
https://www.youtube.com/watch?v=oeNYtYuhZQ4&t=2s
I need assistance in running my test scripts built-in Java platform with selenium webdriver using Eclipse IDE for my repo and used git to push my repo to Azure DevOps. The project is set up in Maven. How do I run my test scripts using pipelines in Azure DevOps?
Not sure get more details from you. So here just share my suggestion on how to run Selenium tests in the release pipeline for Java application.
In my scenario, I deploy my Java application to azure web app service then run it. If you don't want, you can also deploy to local tomcat by using this extension.
1) After the Java application build, copy the project to the artifact of the release during Build pipeline via copy files and publish artifact task.
2) Create release pipeline, then add Azure app service task to deploy my Java application to azure.
3) Add a Maven task to the release pipeline, configure the task to make it point to pom.xml file which located in artifact.
4) Trigger the Selenium tests in pom.xml.
Now you can run browser to view the test.
You can check this lab blog to get more details. Just focus on the design logic of pipeline execution, because the sample in that blog is running with vstest.exe.
We're using Teamcity CI for build and Octopus Deploy for deployment.
We want to use Builtin Octopus deploy repository for storing Artifacts instead of teamcity repo. What are the differeneces between them?
Can you help me evaluate the built in Octopus repository. Pro/Cons, any complications you might be facing.
Thanks.
One of the key differences is that TeamCity can be used as an externally accessible NuGet server, but Octopus Deploy can't expose any packages it knows about. If you're building components in TeamCity that are exposed as NuGet packages and reused within applications then Octopus Deploy won't be able to handle that scenario.
If you're just building applications and exposing them for Octopus Deploy then my advice would be to push them to Octopus Deploy to manage, otherwise you end up duplicating on disk space as there'll be a copy of the package in TeamCity and a copy of the package in Octopus Deploy once it has downloaded it from the TeamCity NuGet feed.
Hope this helps.
The inbuilt Octopus Deploy repository allows you to automatically create and deploy a release as soon as it is packaged and published (usually during a server build). This is great if you want to schedule nightly builds so that your development/test/integration environment is always update to date.
External package repositories cannot be used to automatically create
releases, only the built-in package repository is supported.
It also maintains packages through a retention policy so you don't have to worry about running out of disk space.
We use two NuGet repositories. One for application packages deployed through Octopus Deploy, and one for shared packaged reusable components using NuGet.Server.
I am using VSTS Release management to deploy artifacts to IIS websites. I have several Web applications and web services to be deployed. So, i am trying to figure out what sort of tasks that best fits my situation.
I have created a build definition with Visual Studio Build Task for projects as this one:
which works fine but i need to add a task for copying the artifacts Under IIS Website Directory.
The other approach is to use IIS web deployment as a task in Release definition, so I created the build definition as:
However, it expects a Publish Profile (the build fails because it can't find it). I don't need to create a publish profile for each project in the application because this would be too much work.
Is there is a workaround for that or what is preferred approach for this?
You can update your build definition to generate a web deployment package and upload it to artifacts. And then in Release Management, add a task to run "projectname.deploy.cmd" in the deployment package to deploy it to your IIS server. Refer to this link for details: How to: Install a Deployment Package Using the deploy.cmd File Created by Visual Studio.
And you can also enable FTP Publishing on your IIS server and add a task in your release to publish the artifacts via FTP. You may need this task:
FTP Uploader.
My Continuous Delivery with TFS / VSTS – Server Configuration and Application Deployment with Release Management blog post (with reference to some previous posts) has all the details you need for deploying your artefacts to target nodes using Windows Machine File Copy tasks then use PowerShell on Target Machines tasks to get them in to correct locations and to do token replacement and anything else that's required.
I would recommend using PowerShell DSC so that IIS is properly configured before deployment but that's not required. Where possible for web apps I favour keeping things very simple by creating artefacts that contain all the web files that are needed for a particular folder and then just using plain xcopy for the deployment.
If you need more control you can also use my MSDeploy VSTS extension to deploy a MSDeploy package
https://marketplace.visualstudio.com/items?itemName=rschiefer.MSDeployAllTheThings
https://dotnetcatch.com/2016/04/20/msdeployallthethings-vststfs-extension-is-public/
I'm trying to use TFS 2015.1 on premise to build a CI pipeline for our dev & uat. I've created a vNext CI build, which builds fine. But when I want to add a deploy step for on prem IIS server, I only then see Azure Web Deployment options.
Ideally I wanted to add a step which uses the existing deploy (MS Deploy) profiles, which I'm able to use from VS2015 directly, using 'Publish'. However I see no option to do so.
How can I deploy the latest build to internal dev servers (not Azure)? I would like to use the MS Deploy option, unless there's a better way of doing it?
The fact that their is no option to starts to make me think there's probably a different way to accomplish it!
Thanks.
If you're able to upgrade to TFS 2015.2, web-based Release Management came out with it that works similarly to Build vNext with flexible and open-source tasks. You can also customize tasks.
Here's a link for IIS Web App Deployment from the vso-agent-task's GitHub repo where Microsoft stores updated versions of their tasks that you can download for web-based Build and Release Management.
I'll be publishing a blog about web-based RM with TFS 2015 Update 2 or VSTS on my website in the next few weeks. To give you an idea though, the starting point (for a web application) is a folder in your web project called WebDeploy (no significance - any name will do) that contains a PowerShell DSC script that configures the server, deploys the web files and then replaces any tokenised configs. To give you an idea see this post about how to use DSC to configure servers. (Only covers part of the final script though!) The next steps are:
In the build hub create a Website artifact - containing your web files and DSC script.
In the release hub for an environment use a Windows Machine File Copy task to deploy the artifact to a temp folder on the target node.
Then use a PowerShell on Target Machines task to execute the DSC script. After configuring the server the script copies the web files to their proper location, sorts out config using xReleaseManagement and cleans up the WebDeploy folder.
See this article for general details of the route I'm taking, but watch out as it has some errors eg the firewall instructions are incomplete (file and print sharing through the firewall needs to be enabled).
I can thoroughly recommend the PowerShell DSC route - I've had a few glitches but on the whole it feels very productive and the right way to be going.