Feature list

Legacy Uncategorised
1

Hi!

We are currently evaluating Octopus Deploy for our company and are trying to match Octopus’ feature list with our requirements.

Question 1: Is it possible to:

  • Manage MSSQL databases (e.g. create databases, add users, grant access rights) using Octopus?
  • Manage Windows event logs?
  • Create IIS web sites (it looks like we can only target existing IIS web sites?)
  • Manage scheduled tasks
  • Nice to have: Certificate deployment, MSMQ management, Windows Server role/feature installment

The demo app’s “Add step” button didn’t show a very broad range of possibilities … however, maybe not all features are available in the demo app.

Question 2: Is undeployment also possible? I.e. remove all deployed artifacts.

Best regards,
Dominik

2

Hi Dominik,

Thanks for getting in touch!
For your first question, Yes it is all possible but mostly through PowerShell scripted steps.
Our library has quite a few steps already added that would handle a few of your points.
https://library.octopusdeploy.com/#!/listing
Speaking of the library, it adds step templates to the “add step” options, but we do not have these added in our demo site.

For your second question, no the type of undeployment you are asking about is not possible.
You could say our stance is pro-deployment :wink:

Hope that helps!

Vanessa

3

Thank you for your answer.

4

A follow-up question: if you do not support undeployment of components: how do you prevent flooding a server with thousands of versions of the same software?

E.g.: our nightly build is deployed once per day to a staging system: after a week we would have 7 versions of the software on our staging system?!

5

@Dominik Rauch I am not an Octopus employee, only a user, but I can say we have never looked back once we adopted it.

In terms of flooding a machine with deployments, much like deploying any software to a machine that has an older version, it updates it. For example, files would overlay the existing ones, websites would update directories, database updates would run on existing databases, etc.

6

Hi Dominik,

I think our issue here is the term ‘undeployment’ and my vs your interpretation of it.
I thought maybe you meant it as a term to take a deployment and completely remove it - un-deploy.
But reading your comments, I think you are asking about cleanup of old installs for a current deployment.
Then yes, we have retention policies that tell Octopus how long to keep the old files on the server they were deployed to and clean them up after this time expires.

Am I getting closer?

Vanessa

7

Now, your initial understanding was right: I am thinking about removing deployments from a system. E.g. “remove version 1.4.3.2 from staging system”.

Otherwise we would end up with a lot of parallel versions on the staging system (1.4.3.1, 1.4.3.2, … etc.). “Overwriting” is not an option for us.

Best regards,
Dominik

8

Hi Dominik,

This is exactly what the retention policy deletes as I linked to in the previous post.
It will do your ‘undeployments’ for you.

Cheers,
Vanessa

9

I’m a little bit confused by the docs: “will delete the NuGet package file and the directories that Octopus installed the package to”

Examples:

  • Deployment of a web site to an IIS server: the retention policy would delete all the deployed files (HTML, dlls, etc.) but not the configured IIS application?
  • Deployment of a Windows service: the retention policy would delete the service executable but not the Windows service itself? I.e. the service would fail to start in the future?

What exactly is removed by the retention policies?

10

@Dominik, maybe going through the steps would help make this clear.

When you deploy a package, it transfers the nuget package over to the target machine. Once the nuget package is there, it unzips the files to the directory you specify, and then performs any other necessary actions based on what you want it to do (register a windows service to point to an executable, or setup an IIS site pointing to the directory, etc.)

The retention policy you set only determines when the nuget packages will be deleted. We prefer to keep a few nuget packages from old releases on our CI machines. This helps so that if we have to roll back to an older release, the packages already exist, and all it has to do is unzip them instead of having to transfer the packages over the network.

Retention policies won’t delete the files and such that are in use. I use Custom Installation Directories (supported by Octopus) so that IIS sites and windows services aren’t running from the Octopus directory, but something much more apparent, like C:\Test\Service.

That being said, you never have to worry about having multiple versions of a site or service. If you install version 1.0 of a windows service to C:\Test\Service and 1.0 of a site to C:\Test\Site, it will handle setting the service and IIS configurations. When you decide to install 1.1 the next day, it will transfer the nuget packages, unzip them, turn off the Site and Windows service, place the unzipped files in C:\Test\Service and C:\Test\Site respectively, and restart the service and site. That way, any links you have between them, or any users on the machine, won’t have to change a thing. They might not even know it’s been updated.

There are ways to have multiple deployments exist on the target machine at the same time, but you have to go out of your way to set something like that up. (Can be helpful, but is often the exception.)

Your concerns of having existing packages fill up the machine are handled by the retention policy you set, and your concern of multiple versions existing simultaneously are handled the same way .MSI packages are, or any program that updates.

If you have any other questions, I’d be happy to help.