Self Service - Single Machine

Legacy Uncategorised
1

Hi Octopus,

I’m looking to see how Octopus would cover the following scenario :

New developer / QA joins the company. Given a new machine and told to go to Octopus to pull down the latest release.

The only way I can envisage this is that the environments of Dev / QA have the new machine added and then a release created, but removed all machines apart from this newly added one.

The other option is to create an environment per machine which to deploy to. This isn’t a great option as they would show up on the dashboard and create general clutter for what is a throw away action.

Is there another, more simpler action that I didn’t consider ?

Thanks

2

Hi Jon,

Thanks for getting in touch! When deploying a release, you can click the Advanced link, and select specific machines to deploy to - e.g., the developer would just select their machine. So this could certainly work.

That said, Octopus is really designed for deployments of websites and services to servers, not to workstations. I’d be curious to understand your use case a little more?

Hope that helps!

Paul

3

Hi Paul,

Our setup is slightly outside of what I believe your norm is, but I think it will still work. Let me talk you through it :

Servers :
SQL Server(s)
Application Servers with .Net assemblies and services
Web (IIS) with Web and Web Services.
Client machines with Winforms (installed via MSI)

I have been through a small scale proof of concept and have pushed MSI’s out to client machines, uninstalled the old install and installed the latest. So I can use Octopus to achieve the client side actions.

My concerns come from, as we are not using Octopus wholly for what it is designed that some of the (yet to be thought of) use cases aren’t supported (such as single client self service). Additionally as our usage probably isn’t on your road-map that a future release will prevent us from using Octopus Deploy, therefore leaving us on a later version.

If you have any thoughts about how we are using your software I would be happy to hear back.

Thanks
Jon

4

Hi Jon,

Thanks for the extra details! What you’ve described makes sense, and we do have some other customers doing similar things. The core features you are relying on - Tentacles calling PowerShell - will always exist, so I don’t think there is any risk of us no longer supporting the features you need. While the scenario isn’t one we explicitly set out to support, the mechanisms you’re using are pretty core to Octopus so I don’t see any risks there.

Hope this helps,

Paul

5

Thanks Paul.

6

My local practice might help you Jon.

When working on a tricky deployment related problem that I know needs to be tested locally before checking in, is to experiment against a locally hosted VM.

On my physical workstation (not server) I have installed an Octopus instance. This instance is only really used when I fear impacting my team members.

This instance has my 2 or 3 locally hosted VMs added to it only. Note: these VMs are not added to our 'shared’l Octopus instance.

Then I use the OctoTools utility to export the project from the shared Octopus instance to my local one. Then I begin my development work.

I actually find this to be a good exercise for a new hire because they have to perform a number of task which help end to end understanding of your product:

  • create a VM and configure as needed
  • install Octopus
  • install tentacle
  • export/import project
  • deploy
  • execute that code and see the results

Hope that helps. You can consult the documentation on export/import command syntax.