I have build scripts that builds, test, version and packages my projects as artifacts to a staging area for each of our environments ready for a versioned release to a given environment (and labels the changeset).
I want to stop doing this automatically and only deploy on demand.
My problem is I am using TFS and the friction is just immense.
I basically want to have an easy way to
Get a specific version from source control
build it for a specific enviroment -DONE
deploy it. -DONE
The last 2 steps are trival. The "getting by label" it not that much fun with TFS.
Any ideas/pointers other than use stop using TFS?
just ask on twitter next time :-)
Seriously though, have a look at TFS Deployer on codeplex. The way it works is that you do a normal build with versioning of the output like you normally would, but you pull out all the deployment stuff from it.
Next, setup TFS Deployer - it listens for changes in the Build Quality and the fires off a powershell script that you write that does all the deployment work. For example, when you change the quality of a build to something like "deploy to UAT" it can fire off a powershell script that then does whatever you need it to. To do a deploy you just go to build explorer, set the quality to whatever you want and let powershell do the rest - you'll get an email of the results as well so you know if it works or fails.
Go have a look at it and if you get stuck just ping me and I'll help you out.
Related
I've been trying for a week to deploy a webrole to Azure Clous Services without quite getting there.
Here is my setup:
I've got a cloud solution with a cloud project and a MVC application (standard no changes to template yet). Its under source control in Visual Studio Online.
I'm using octopack to try generating the nuget package
I'm using the buildt in nuget repo from Octopus
The Octopus server and tentacle is hosted on a VM in azure
I've created a step-template for my deployment step (see this article)
My plan:
I'd like to have a CI build to a dev-service and a seperate build to push my project to the staging environment and roll it onto the production environment using Octopus.
My problem:
The packages that are produced by Octopack seems to not contain what they should. And I've tried to play around with the nuspec file included in my webrole to get it just right. Something ends up missing either way i try.
Have anyone gotten this to work? I'd appreciate any tips pointing me in the right direction as I've slowly been running out of ideas. So i turn to you my fellow nerdlings for some much needed help.
Regards
ZiGGstern
Correct me if I'm wrong but it looks like you're in need of the octo.exe to automate deployments after build within Visual Studio/TFS Online to your target environments.
I'm trying to focus on this statement:
I'd like to have a CI build to a dev-service and a seperate build to
push my project to the staging environment and roll it onto the
production environment using Octopus.
You can configure within your build-template, using the "Post-Deploy Script Path" a PowerShell script to call the Octo.exe (with an API Key) and fire off a deployment for your desired environment(s). You can customize this per build if you so choose. I've used this method by creating a folder within the root of my Solution (I call it 'Tools' but the name doesn't matter). Within that Tools folder, I add a PowerShell script AND the octo.exe. The PS script fires the Octo.exe which makes a call to my Octopus Server and with the "create release" option, I'm able to automatically deploy to whatever environment AFTER my build finishes within TFS. Make sure to always include those files (right-click in VS and in file properties select 'always copy').
I'm not quite sure why your NuGet packages would not be configured correctly, but that should be remedied first. Your question is trying to ask for two things and it's not clear which is more important to you; NuGet package or the Deployment from CI build. Having said that, I think you need to give more details on why you think your NuGet package is inadequate or not working correctly for your Azure services.
Please note, the site you supplied is using a custom PowerShell script in the form of a step template. It may be best to try the default Azure step within Octopus first before using a customized script. Just a thought.
Read more about the Octo.exe here: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596
Our plan is to use Team Foundation Build service to do automatic builds, then use the testing facility to automatically perform testing on the build server then release that build onto the application server.
So far we have
Team Foundation Server with TF Build Controller configured
Build server with win2012, Visual Studio 2013 and Build agent configured.
SQL Server with SQL 2013 installed
Application Server with Win2012 and .netframework installed
My question is what do I need to do to set up automatic builds, and to execute the unit test harness once compilation is successful.
Also the deployment target machine will initially be DEV, however we would like to quickly build for test env and prod etc.
This is what I got so far.
Build Controller (Already set up I believe)
Build Agent (Already installed on build server)
Build Process Template (Do I need to do anything with this. Is this what controls the whole lot)
Team Build Definition (I had a look at this, and it seems to use the build process template)
Drop Folder (I am assuming this is where the executables will be dropped into).
At the moment I have bits and pieces of info, what I would like to know is how this whole thing is hanging together. From the moment the developer wants to do the build to the moment that exe is placed into the DEVAPPSERV (Development application server).
Is anyone able to point me in the right direction or give a summary of what I need to make this happen?
Many thanks,
Dalibor
Install TFS Server (TFS Disk) Create a Team Project Collection and any desired Projects
Install TFS Controller + Agents onto a dedicated machine (TFS Disk) Configure only the build options if on a different machine to the TFS Server
Configure Build Controller to connect to a Specific Team Collection on your TFS Server
Install VS Premium or higher on build machine, if you want code coverage results for your tests
Add some code to TFS Source Control
Create a Build Definition using the default template.
Configure the build definition.
Set the working folder for the build, include only what you need as this will speed up the process
Point the definition to your .sln or proj file.
Ensure testing is enabled and that your test assembly names will match the regex used to identify test dll's i.e. name your test assemblies with the word test.
Set the trigger to be CI or what ever flavour of build you require i.e. gated build
Save the build definition
Trigger a manual build and debug any issues
you should have the basics done and a repeatable build created.
That should cover the basics, you may want to customise the build template (see Ewald Hoffman's guide for tips), you may want to narrow down your code coverage (look for runsettings file info).
If you follow these steps you should be able to get a basic build created and running from these, if you hit any issues you can come back and ask specific questions about a particular area
In order to do automatic builds you should check the CI build option ( under the trigger build option ) and third party automated testing can be run by executed by a post build script.
See the following TFS article about post build scripts.
http://msdn.microsoft.com/en-us/library/dn376353.aspx
Currently we have a build process as follows:
I do a build into our dev staging environment.
I label this in TFS.
I use SVN bridge to check out that changeset that was labelled.*
If testing for dev staging passes, I use the working copy I checked out to do another build into the next environment.
I don't want to have to use SVN Bridge to have a copy of my code somewhere else for code at a specific version, but I have not found a way to do this natively in TFS (2010).
Is there a way of doing this (point 3 and 4) using TFS, instead of SVN Bridge?
I may be completely misunderstanding what you're trying to do, but it sounds like you need to create a separate workspace, and get the code that was labeled in step 2 into the new workspace.
I have a team foundation server with build server, when I run a build it deploys to a website on that box. However I also want to do the same on Production which is a server on an external network and not part of the same domain.
I thought about looking at TFS Deployer but that just seemed to work within a network, I'm going to test it out as soon as I get a chance but I thought the best idea was to ask here when working with something so critical.
Is it a really bad idea to have a way of easily deploying to production?
Does anyone here deploy to production using whatever method? How do you do it?
Essentially the accepted answer will go to the person who can tell me the best method for achieving a deployment but pointing me in the right direction is sure to get an up vote as long as it's not too obvious.
Depending on the infrastructure you have available to you you can use wix to create msi's and use SMS configuration manager to deploy them to a target collection. This is the direction that we are moving to but have not reached yet. We also integrated wix into our build process to create the MSI artifacts. The reason we wanted to go down this path was because we are using CruiseControl.net as our continuous integration server and we have a nant script that we use to perform both the build process and the deployment process. They are both separate targets in the nant file, but what we wanted was a consistent model of deployment to all environments including production.
What are are doing currently is we are manually moving zips (which are artifacts of our current build process) to production. When the zips are unpackaged in the production environment we have to remove all the web.config, app.config etc from the zips and if we have new entries in the configs they are made manually.
Found msdeploy http://blogs.iis.net/msdeploy/archive/2008/01/22/welcome-to-the-web-deployment-team-blog.aspx
I'm working on my first rails app and am struggling trying to find an efficient and clean solution for doing automated checkouts and deployments.
So far I've looked at both CruiseControl.rb (having been familiar with CruiseControl.NET) and Capistrano. Unfortunately, unless I'm missing something, each one of them only does about half of what I want (with each one doing a different half).
For what I've seen so far:
CruiseControl
Strengths
Automated builds on repository checkouts upon commit
Also runs unit/functional tests and reports back
Weaknesses
No built-in deployment mechanisms (best I can find so far is writing your own bash scripts)
Capistrano
Strengths
Built for deployments
Weaknesses
Has to be kicked off via a command (i.e. doesn't do automated checkouts upon commit)
I've found ways that I can string the two together -- i.e. have CruiseControl ping the repository for changes, do a checkout upon commit, run the tests, etc. and then make a call to Capistrano when finished to do the deployment (even though Capistrano is also going to do a repository checkout).
Basically, when all is said and done, I'd like to have three projects set up:
Dev: Checkout/Deployment is entirely no touch. When someone commits a file, something checks it out, runs the tests, deploys the changes, and reports back
Stage: Checkout/Deployment requires a button click
Prod: Button click does either a tagged check out or moves the files from stage
I have this working with a combination of CruiseControl.NET and MSBuild in the .NET world, and it was fairly straightforward. I would guess this is also a common pattern in the ruby deployment world, but I could easily be mistaken.
I would give Hudson a try (free and open source). I started off using CruiseControl but got sick of having to relearn the XML configuration every time I needed to change a setting or add a project. Then I started using Hudson and never looked back. Hudson is more or less completely configurable over the web. It was initially a continuous integration tool for Java but has plugins for other development stack such as .NET and Ruby on Rails. There's a Rake plugin. If that doesn't work, you can configure it to execute any arbitrary command line after running your Rake builds/tests.
I should also add it's extremely easy to get Hudson going:
java -jar hudson.war
Or you can drop the war in any servlet container.
I would use two system to build and deploy anyway. At least two reasons: you should be able to run it separately and you should have two config files one for deploy and one for build. But you can easily glue the two systems together.
Just create a simple capistrano task, that tests and reports back to you. You can use the "run" command to do anything you want.
If you don't want any command line tool there was webistrano 2 years ago.
To could use something like http://github.com/benschwarz/gitnotify/tree/master to trigger the build deploy if you use git as repository.
At least for development automated deployments, check out the hook scripts available in git:
http://git-scm.com/docs/githooks
I think you'll want to focus on the post-receive hook script, since this runs after a push to a remote server.
Also worth checking out Mislav's git-deploy on github. Makes managing deployments pretty clean.
http://github.com/mislav/git-deploy