Setting up continuous deployments with Octopus Deploy and TFS

You may also like...

8 Responses

  1. Daniel Revell says:

    I’m curious that your technique differs from that in the octopus documentation. We have and we use the OctoPack package on the deployable projects. You do this too and specify your API key twice, once in the build arguments for OctoPack then again in your script for pushing via octo. If octopack can do the pushing to a new release too, then why don’t you use just that?

    • ianpaullin says:

      Hi Daniel,

      The OctoPack doesn’t trigger the new release – all it does is upload the NuGet package to the NuGet feed after the TFS build is done. You’re getting confused with the API Keys. The first one is for the OctoPack to upload to the NuGet feed and the second API key is for the Octopus Server.

      The API Key that’s used by the octo.exe contacts the Octopus Server (not the NuGet feed) needs to have the appropriate permissions to trigger the release for the deployment to occur but it’s not the same as the NuGet feed API Key. The octo.exe needs to be triggered after the new build is uploaded to the NuGet feed. I hope this explanation helps.

  2. BMK says:

    Interesting Ian,

    Thanks for the post; We do automated deployments using TFS and Octopus. The Release in Octopus is created as soon TFS build pushes the package and in our lifecycle definition we have flagged our DEV region for automated deployments, which automatically deploys the application once the new release is available. That is just with outbox features without any custom scripting.

    • ianpaullin says:

      I assume you’re using the Octopus server’s built-in NuGet feed – that makes automated deployments much easier as you can tell Octopus in the portal UI to just automatically deploy to a given environment upon a new package being uploaded. But if you’re not using the the server’s built-in feed, you need to use the script I mentioned above or some other similar mechanism to trigger Octopus to deploy after you’ve successfully built a NuGet package.

  3. Jeff says:

    We have a need to target several physical machines for a deploy and need to coordinate what is essentially a 3 phase process across all the boxes:

    1) Bring all machines down to maintenance mode (stop services etc)
    2) Deploy new code to all machines
    a) This *may* also require serial sequencing, box A then box B
    b) In other cases they are all parallel
    3) Bring all machines back up to running mode (restart services etc)

    Is there anything built into the octo process to help cater to this senario? Any suggestion on how to crack this nut?

    • ianpaullin says:

      I’m not sure if I understand the question. The octo.exe doesn’t really do the work – it just triggers a project’s deployment process. The “–deployTo=” option will actually deploy the newly created release to whatever supplied environment you’ve passed along. All your steps can be done within the deployment process, but you’ll have to be more definitive about your points A and B in step #2 – when serial vs.parallel work should be done.

      • Jeff says:

        Ignore my 2.a and 2.B, they really are not needed to illustrate the point. Just go with the 1,2,3 bullets.

        This really just a question about coordinating a deployment across several physical system which act logically as a single solution. Think DB server, Web Server, and App Server. I need for example to bring the App Server down to maintenance mode (stop all the win32 services) before upgrading the DB Server. Or as another example on bringing the system back up for use after the deploy I might need to restart all the services on the App Server before allowing the Web Server back online.

        I have the process needed for each of the system types scripted/automated and can (and do) today run each in an automated way….but I have to do each in turn manually. Essentially my process today is:

        1) Shut down IIS on the web server
        2) Shut down Win32 services on the App server
        3) kick off the deploy scripts on each box
        a) start DB server deploy scripts on that system
        b) start the App Server deploy scripts on that system
        c) start the Web Server deploy scripts on that system
        d) monitor fopr completion of all 3 of these
        4) restart the Win32 services on the App Server (or at least make sure they automatically come back up clean)
        5) restart IIS on the Web Server.

        Because these scripts/processes span several machines I’m looking for some means to coordinate the processes.

        In another slice of life I use Jenkins for builds/automation/etc and I know I can build some multi node coordination with jobs using various linkages and downstream plugins etc. I’m wanting to know if any of the infrastructure in octopus can help with this coordination.

        That help?

Leave a Reply

Your email address will not be published. Required fields are marked *