522 results found

1. Support ZIP(compression) of files/folders

   Most of our deployments begin by first copying existing deployed files/code to another folder as a backup. This is required in case a quick rollback is required.

   Would be nice if I could zip those files to save disk space.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployments  ·  Delete…  ·  Admin →

2. Add an option to notify members of the responsible team on Manual Intervention Steps

   When adding a manual intervention step (say for approval to deploy to production) It would be nice to have a checkbox on the step configuration that sends an email to all users of the "responsible teams" containing the instructions and a link to the release.

   While we're on the subject, it would also be great to be able to set a Team as an addressee on the the Send Email step template.

   38 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   3 comments  ·  Deployments  ·  Delete…  ·  Admin →

3. Octopus server "linking"/clustering

   I haven't thought this through 100%, so i'm just going to ramble a little..

   We're sitting in a PCI environment where we're required to have a separate installation of Octopus in our production environment. Currently, the solution is to have our build server push packages to both our internal and production environments (we're allowed to use HTTPS over a site-to-site VPN for specified services).

   The biggest downsides to this are that:

   1) Without setting up complex build configurations for each project in our CI server (time consuming and maintenance nightmare), all packages get pushed to the production environment, even if the releases are later rejected in QA/UAT.

   2) Increased risk of human error since we can't use the "promote" workflow.

   3) Must manually re-create and configure projects in the production environment (human error risk as well).

   It would be superb if we were able to link these two instances together via an HTTPS connection where:

   1) Once a release reaches a specified "gate" (e.g. UAT release accepted), the release could be promoted to a linked Octopus server instance (push nuget packages, etc.), where the production release could be handled from there (we have separate logins to our production Octopus). I suppose the release could be flagged as "pending release" or something in the dashboard, indicating action needed. In this case only accepted releases would end up in the production environment.

   2) Specify which projects can/should be synced to which linked servers (in-case of several separate environments running different projects).

   3) Flag variables as needing to be re-configured in the production environment (e.g. we would rather keep our production connection strings only on the production Octopus instance, and not specify them in the internal instance). A promote-to-instance should fail if these haven't been re-configured.

   4) It would be nice to be able to visualize the release status in environments on linked servers.

   And naturally there's a lot of other nifty features/etc. that could be built around/on-top of this...

   I haven't thought this through 100%, so i'm just going to ramble a little..

   We're sitting in a PCI environment where we're required to have a separate installation of Octopus in our production environment. Currently, the solution is to have our build server push packages to both our internal and production environments (we're allowed to use HTTPS over a site-to-site VPN for specified services).

   The biggest downsides to this are that:

   1) Without setting up complex build configurations for each project in our CI server (time consuming and maintenance nightmare), all packages get pushed to the production environment, even if… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployments  ·  Delete…  ·  Admin →

4. Enable a failure/success variable to be used in the email subject

   We would like to create one step template that will send an email to the developers with the deploy result.
   It would be nice to have a variable like Octopus.Deployment.Result to include the deploy result in the Email subject.
   As far as I can see you can not use powershell or the if structures from the Email body?

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Deployments  ·  Delete…  ·  Admin →

5. Show OS and Powershell version for each tentacle host

   We have numerous Windows servers running the Ocotpus tentacle service. These servers are running various versions of Win2008, 2012 and powershell. Different Octopus powershell scripts have different minim powershell versions so it's important to make sure that powershell is the correct version on each server. It would be very helpful if we could see environmental info such as Windows Version and Powershell version for each tentacle machine (perhaps on the machine settings page in Octopus)?

   15 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployments  ·  Delete…  ·  Admin →

6. Make OctoPack an developmentDependency

   OctoPack is a build time tool not a project dependency.
   Adding the developmentDependency attribute will allow other tooling understand this.

   see http://nuget.codeplex.com/workitem/1956 for more info on developmentDependency attribute.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployments  ·  Delete…  ·  Admin →

7. Allow Octo.exe create-release command line to specify an alternative NuGet feed than the one(s) indicated on the steps of a project.

   Allow Octo.exe create-release command line to specify an alternative NuGet feed than the one(s) indicated on the steps of a project.

   We have a DEV feed which is used for all development builds and development deployments. Due to circumstance beyond our control, we cannot have our development environment match all other environments close enough to want to promote releases from development.

   We have a MAIN feed that is for all other environments (QA, TRAIN, PROD).

   The problem we have is that a deployment step is tied to a specific NuGet feed. This means having to maintain two versions of a deployment project: one that gets from the DEV branch and one that gets from the MAIN branch. If we could set a parameter on the create-release command to override the feed for a specific step (or for all steps), we could eliminate the redundant projects. Alternatively, if the feed could be a variable, that would work, too (though that probably creates a problem because the Step Details editor needs to know what feed to use to validate the NuGet package ID.)

   Allow Octo.exe create-release command line to specify an alternative NuGet feed than the one(s) indicated on the steps of a project.

   We have a DEV feed which is used for all development builds and development deployments. Due to circumstance beyond our control, we cannot have our development environment match all other environments close enough to want to promote releases from development.

   We have a MAIN feed that is for all other environments (QA, TRAIN, PROD).

   The problem we have is that a deployment step is tied to a specific NuGet feed. This means having to maintain two versions of a… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Deployments  ·  Delete…  ·  Admin →

8. Variables in NuGet package ID per enviroment

   It would be great if the NuGet package ID could contain a variable that was resolved on a per environment basis instead of only once when the deployment is created.

   We have the same process for each client with a different installer and out current solution has been to package them all into single NuGet package and then grab the correct one on a per environment basis with a powershell step.

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Deployments  ·  Delete…  ·  Admin →

9. Enable the user to define a default release behaviour for each step in a project

   When creating a release the user is given three options to configure a package version for each step, Latest, Last, Specifc. The default is Lastest.

   Allow the user to specify the package version default behaviour in each step.

   The user could then ensure a package stays at a particular version without having to set the version each time they create a release.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployments  ·  Delete…  ·  Admin →

10. Visual progress in the task log

    When you're monitoring a deployment in progress, you watch the task log growing as it's adding more content to the bottom of the page, but that requires you to keep scrolling the page.

    It would be helpful if the task log page scrolled down automatically, or if there was some other way to keep the most recent update in view, so you can keep your eyes focused (quite literally) on one spot on the screen.

    I think this would give a more "solid feel" to keeping track of the deployment's progress. When the pressure's on during a difficult/risky deployment, this can really make a difference.

    When you're monitoring a deployment in progress, you watch the task log growing as it's adding more content to the bottom of the page, but that requires you to keep scrolling the page.

    It would be helpful if the task log page scrolled down automatically, or if there was some other way to keep the most recent update in view, so you can keep your eyes focused (quite literally) on one spot on the screen.

    I think this would give a more "solid feel" to keeping track of the deployment's progress. When the pressure's on during a difficult/risky deployment, this… more

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Delete…  ·  Admin →

11. Add support for a tool library

    Currently when we need some tools (sqlpackage.exe, sqlcmd.exe, some DLL...) to be present on the tentacle for our deployment script we create a NuGet package with the tool and have to manually add a Deploy Package step for each tool to deploy it in a standard path so we can then use them from PowerShell scripts/

    It would be great to have a tool library:
    - we create a tool by specifying a NuGet package, a name and a description
    - in each steps (template steps or process steps) we can specify which tools is needed
    - when deploying the tentacle will manage the download of the tools if not already present and add a PowerShell variable with the path where it was installed. (with a tool names SqlPackage we will have an $OctopusParameter['SqlPackageToolPath'])

    Currently when we need some tools (sqlpackage.exe, sqlcmd.exe, some DLL...) to be present on the tentacle for our deployment script we create a NuGet package with the tool and have to manually add a Deploy Package step for each tool to deploy it in a standard path so we can then use them from PowerShell scripts/

    It would be great to have a tool library:
    - we create a tool by specifying a NuGet package, a name and a description
    - in each steps (template steps or process steps) we can specify which tools is needed
    - when deploying the… more

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Delete…  ·  Admin →

12. Use nuget dependencies to track dependency between projects in a given environment

    I have read the section on not using dependencies (http://docs.octopusdeploy.com/display/OD/Packaging+applications) and I agree but I think we're missing a nice feature if we consider dependencies as being releases done by Octopus to a given environment that include the nuget that is defined as a dependency. Consider this:

    MyOrg.MyApp.Web 1.0.0.0 depends on MyOrg.MyServiceApp.RestApi 1.5.0.0...2.0.0.0.

    When I deploy MyOrg.MyApp.Web to environment Production Orcopus could check if I have a release in that environment that deuccessfuly deployed MyOrg.MyServiceApp.RestApi 1.5.0.0...2.0.0.0. Essentially this would make sure all my dependencies between projects are deployed within a given environment.
    It could also warn me about incompatibilities between projects when I would deploy MyOrg.MyServiceApp.RestApi 3.0.0.0 to production when I have MyOrg.MyApp.Web expecting a different version.

    I have read the section on not using dependencies (http://docs.octopusdeploy.com/display/OD/Packaging+applications) and I agree but I think we're missing a nice feature if we consider dependencies as being releases done by Octopus to a given environment that include the nuget that is defined as a dependency. Consider this:

    MyOrg.MyApp.Web 1.0.0.0 depends on MyOrg.MyServiceApp.RestApi 1.5.0.0...2.0.0.0.

    When I deploy MyOrg.MyApp.Web to environment Production Orcopus could check if I have a release in that environment that deuccessfuly deployed MyOrg.MyServiceApp.RestApi 1.5.0.0...2.0.0.0. Essentially this would make sure all my dependencies between projects are deployed within a given environment.
    It could also warn me about… more

    18 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Delete…  ·  Admin →

13. Add support for msdeploy package-style parameters transformations

    This discussion started as a support thread here:

    http://help.octopusdeploy.com/discussions/questions/2571-web-package-based-parameters

    Let's say I have an App.config for a Windows Service that looks like this:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <!-- snip -->
      <system.net>
        <mailSettings>
          <smtp from="user@localdomain.org">
            <network host="smtp.local" />
          </smtp>
        </mailSettings>
      </system.net>
      <!-- snip -->
    </configuration>
    

    With the built-in transformations (appSettings and connectionStrings) I cannot replace the SMTP server host.

    For web projects in the past, I've used msdeploy (or web deploy) package parameters to do this transformation from environment to environment.

    The idea is you create a parameters.xml file locally to your project, and then each environment has a corresponding setParameters.xml file that defines the values for the defined parameters.

    So, a parameters.xml file would look like this:

    <parameters>
      <parameter name="Smtp Server" description="Address to server that provides smtp" defaultValue="smtp.dev" tags="" >
        <parameterEntry kind="XmlFile" scope="\\Service.exe.config$" match="/configuration/system.net/mailSettings/smtp/network/@host" />
      </parameter>
    </parameters>
    

    And instead of the setParameters.xml file typically used, we could just use the Octopus Variables functionality. For the example above, you'd just need a Variable for "Smtp Server".

    I've put something together that works for me for now, but would prefer if something like this could be built in.

    Here's what I've got for now:

    A custom Powershell Script (imported into Octopus Deploy Lirary as a Script module):

    [Reflection.Assembly]::LoadWithPartialName("System.Xml") | Out-Null
    [Reflection.Assembly]::LoadWithPartialName("System.Xml.XPath") | Out-Null
    [Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq") | Out-Null
    
    function Sync-DeployParameters { param($variables, $pathToParameters = "parameters.xml", $fileFilters = @("*.config", "*.xml"))
      $pathToParameters = (Resolve-Path($pathToParameters)).Path
    
      if(!(Test-Path $pathToParameters)) {
        throw "Could not find parameters file: $pathToParameters"
      }
    
      $parametersXml = [System.Xml.Linq.XDocument]::Load($pathToParameters)
    
      $parameters = $parametersXml.Descendants('parameter')
    
      foreach($parameter in $parameters) {
    
        $key = $parameter.Attribute('name').Value
    
        Write-Output "'$key'"
    
        if($variables.ContainsKey($key) -eq $false) {
          Write-Output "No matching variable. Skipping."
          continue
        }
    
        $parameterEntry = $parameter.Element('parameterEntry')
    
        $kind = $parameterEntry.Attribute('kind').Value
    
        if($kind -ne 'XmlFile') {
          Write-Output "parameterEntry is not of kind XmlFile. Skipping."
          continue
        }
    
        $scope = $parameterEntry.Attribute('scope').Value
        $xpathMatch = $parameterEntry.Attribute('match').Value
    
        $pathsInScope = Get-PathsToConfigs $scope @($fileFilters)
    
        if(!($pathsInScope)) {
          Write-Output "Could not find scope: $scope"
        }
    
        foreach($pathInScope in $pathsInScope) {
          if((Test-Path $pathInScope) -eq $false) {
            continue
          }
    
          Set-XPathValue $pathInScope $xpathMatch $variables[$key]
        }
      }
    }
    
    function Get-PathsToConfigs { param([string]$scope, [string[]]$fileFilters)
      $relativelyScoped = "\.$scope"
      return Get-ChildItem . -Recurse -Include $fileFilters | Where-Object { (Resolve-Path($_.FullName) -Relative) -match $relativelyScoped } | %{ $_.FullName }
    }
    
    function Set-XPathValue { param([string]$pathToFile, [string]$xpath, [string]$value)
      Write-Output "$pathToFile - $xpath='$value'"
    
      $document = New-Object System.Xml.XmlDocument
      $document.PreserveWhitespace = $true
      $document.Load($pathToFile)
    
      $navigator = $document.CreateNavigator()
    
      $manager = New-Object System.Xml.XmlNamespaceManager($navigator.NameTable)
    
      foreach ($nav in $navigator.Select($xpath, $manager))
      {
        $nav.SetValue($value)
      }
    
      $document.Save($pathToFile)
    }
    
    Export-ModuleMember -Function Sync-DeployParameters
    

    And then inside my process (Nuget package) that deploys the Windows Service, I have Custom Powershell scripts turned on that execute as a 'Deployment script':

    Sync-DeployParameters $OctopusParameters
    

    This is incomplete; I haven't tested it much. One obvious missing feature is to use the defaultValue specified in the parameters.xml file, but that should be easy to do.

    Is it possible something like this could get built into Octopus Deploy? Or did I miss the whole point and there's an easier way to do this? I've seen the substitute in files feature, but I don't like it as much because I have to keep templates around of my config files.

    This discussion started as a support thread here:

    http://help.octopusdeploy.com/discussions/questions/2571-web-package-based-parameters

    Let's say I have an App.config for a Windows Service that looks like this:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <!-- snip -->
      <system.net>
        <mailSettings>
          <smtp from="user@localdomain.org">
            <network host="smtp.local" />
          </smtp>
        </mailSettings>
      </system.net>
      <!-- snip -->
    </configuration>
    

    With the built-in transformations (appSettings and connectionStrings) I cannot replace the SMTP server host.

    For web projects in the past, I've used msdeploy (or web deploy) package parameters to do this transformation from environment to environment.

    The idea is you create a parameters.xml file locally to your project, and then each environment has a corresponding setParameters.xml… more

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    6 comments  ·  Deployments  ·  Delete…  ·  Admin →

14. Create a step template that applies config transformations

    Have an entry field that accepts the same sort of content as is seen in the transform window here: https://webconfigtransformationtester.apphb.com
    as well as maybe a file pattern/name to match the transformation to.

    This way one can avoid building multiple instances of an application, one for each build configuration (environment), transforms don't happen at build time and can take place as part of a deployment.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Delete…  ·  Admin →

15. Enable one to be able to iterate a list of last installed directory paths for steps in project

    Create an Octopus variable that contains the last installed directory paths for the steps in the project. This becomes useful if you have one step that deploys and another that works on the previously deployed step, but for some reason you deployed one set of steps first and later the remaining steps.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Edit…  ·  Delete…  ·  Admin →

16. Add support for setting Windows Service Recovery options

    Add the ability to set the actions to be taken on service failure. This is accomplished via sc as follows:
    http://technet.microsoft.com/en-us/library/cc742019.aspx or using Powershell set-service.

    At present, we are managing with a custom PowerShell script.

    100 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Delete…  ·  Admin →

17. Run child steps on different roles

    step 1 remove web server from load balancing server(s)
    step 2 deploy website
    step 3 add webserver to load balancing server(s)

    similar to http://octopus-deploy.tenderapp.com/discussions/problems/15836-powershell-child-step-cannot-be-executed-on-octopus-server
    and
    https://github.com/OctopusDeploy/Issues/issues/641

    15 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Deployments  ·  Delete…  ·  Admin →

18. Add the option to disregard pre-release packages when creating a release by default

    I noticed that when creating a release pre release packages show up in the latest column when their version number is the highest available.

    Pre-Release version are usually used for (feature)branches, hotfixes or alpha/beta version of new major releases. All things that deviate from the regular release flow.
    I would prefer having to pick the special version using the specific version picker and only see the latest non pre-release version
    in the "latest" column on the "create release" page.

    A simple checkbox to turn that feature on/off on the projects's settings page would do. That way you could set it differently for each project.

    I noticed that when creating a release pre release packages show up in the latest column when their version number is the highest available.

    Pre-Release version are usually used for (feature)branches, hotfixes or alpha/beta version of new major releases. All things that deviate from the regular release flow.
    I would prefer having to pick the special version using the specific version picker and only see the latest non pre-release version
    in the "latest" column on the "create release" page.

    A simple checkbox to turn that feature on/off on the projects's settings page would do. That way you could set it… more

    11 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Delete…  ·  Admin →

19. Configure Default Deploy Options

    It would be nice if you were able to configure defaults for deploy options. Currently they are all false by default. I never really had a need to check any on a regular basis until Guided Deployments are introduced but now I find myself checking this option with every deployment, which isn't optimal. I'm not sure if it would be best to be able to configure these on a per project level or perhaps project group level but it would be nice to configure their defaults somehow.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Delete…  ·  Admin →

20. Simple way to publish .nupkg files to Nuget.org

    Ability to deploy a nupkg bundle (myCoolOssProject.1.0.0.0.nupkg) up to http://nuget.org whilst being able to leverage the Promote feature built into Octopus.

    I've tried this using a standard approach, but nesting nupkg files doesn't appear to be supported by nuget.exe

    Cross Post:
    http://stackoverflow.com/q/23317526/124069

    11 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Delete…  ·  Admin →