I really want to get started using Octopus to help with our deployments. We currently have our source control checked into TFS, but don’t use any other TFS functionality. Not even task/bug tracking. I have a lot of experience working with SVN and Jira from previous jobs, and I really like the simplicity (compared to the sometimes obtuse way that TFS seems to work). Our engineering team is 2 people with 3 more outside contractors working mostly independently. Our company’s application is 100% .NET C# and boils down to 3-4 libraries, 2 main web applications, a “service API” application, and 2 secondary applications that are rarely updated. Currently, deployments are done by manually copy/pasting bin/DLLs, and sometimes aspx files, onto the servers…and we’re starting to have a few problems with bungled deployments. The applications are rapidly growing and we need to address deployments soon. We’re moving to a new server environment with load balancers and tertiary servers for extra services, and this is the opportunity to put new tooling in place. We have no unit tests for the existing code, so we’ll be using a stage/test environment to approve changes before deployment. And we currently subscribe to do specific development/project planning methodology.
My question is this: Given that we’re dedicated to Visual Studio v.Current and Windows, and that we want to use Octopus to manage our deployments, what’s the easiest way to get CI going, give us better bug/task management, easy administration, automated builds, and (eventually) simple unit testing. Everything that I’ve seen about TFS says that none of that is simple or easy to set up.
So I turn to you, the only community in the .NET space that seems to have CI and automated deployments done right. What’s your recommendation?
Oh, and it goes without saying that we’ll be sending the Octopus team a pile of money as soon as we can get this stuff working.
Easiest way possible is probably Team City 1. It has native support for creating nuget packages and for extra special bonus points since your team is 5 people, it’s free!
I’d second the TeamCity vote. We’ve used it for years, and IMHO it’s the best tool out there for this. For Project Management, we use Pivotal Tracker, but the only rub there is that it is no longer free to use. Some other alternatives I’ve seen used for tasks/bugs are Trello and GitHub’s issue tracking features.
I’d also say that dumping TFS for source control is not a bad idea either. We’ve been using it for 5+ years due to a corporate mandate, but now things have loosened up, and we’re migrating all of our code over to git.
At my previous gig, there were a few fans of Git. But as a .NET developer, it makes me uncomfortable. It just doesn’t work “right” in windows and is too command-line-focused. I understand SVN and TFS for source control. I’m still waiting for “Git for Dummies” or “Git for Mere Microsoft Developers” to be published.
Octopus currently uses Git for source control, Trello and help exchange (and Github tasks for internal bugs) and TeamCity 7. I can definitely recommend TeamCity - I’ve seen it scale from a handful of developers all the way to an investment bank with 3000 active developers. TeamCity’s NuGet feed makes it very easy to use alongside Octopus.
Whatever you’re reading about TFS being hard to setup for CI is probably from people who have never bothered to spend five minutes setting it up. Out of the box you just need to create a buld defnition for your Team Project and point it at the branch of the .sln file you want to build in source control and set the trigger to… wait for it… “Continuous Integration”. Now, every time there’s a check in the build will automatically run. (See attached screenshot)
With the TFS build difficulty myth hopefully quelled, let’s get to the Octopus specifics. Team Build uses Windows Workflow Foundation technology to enable extensibility/customization of the build process. Therefore, to extend the build with Octopus, means you need to write some Windows Workflow Activity classes. It took us about an hour or so to create one activity that invokes the build with Octopak to package up the output for Octopus and another task that allows us to automatically create releases in Octopus using octo.exe create-release and, optionally, deploy that release if it’s a CI build.
We’re not ready to share the code just yet (it’s integrated with some of our other code, I need to tease it out), but when it’s ready I plan on putting it up on GitHub and maybe the Octopus project will incorporate it GitHub suite[1].
Note that this is only necessary if you need TFS to trigger a deployment - if you are just compiling code, running tests, and creating NuGet packages, most of that can be done pretty easily.
I just found this post and we are beginning to look into Octopus deploy. We use TFS as well for our source control. Are there easier ways since this last post or is the link you posted pretty much still the standard?
