Chris Camburn

My feedback

  1. 9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Product Feedback » Deployments  ·  Flag idea as inappropriate…  ·  Admin →
    Chris Camburn shared this idea  · 
  2. 358 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    Under Consideration  ·  39 comments  ·  Product Feedback » Deployments  ·  Flag idea as inappropriate…  ·  Admin →
    Chris Camburn supported this idea  · 
    An error occurred while saving the comment
    Chris Camburn commented  · 

    Any chance of an update? We have a few hundred projects, with only a few project types, and it's becoming cumbersome to manage even trying to script out the API changes to projects.

    An error occurred while saving the comment
    Chris Camburn commented  · 

    One additional request: We use a number of standard settings for IIS, and the current built-in IIS deployment step is perfect, so that we don't have to script everything ourselves. We'd like to use that as a step template, so that any changes to how we deploy IIS sites can apply to all projects at once. Unfortunately, to do that we have to use a variable for the package name, which breaks the retention policy. Unlike most steps where we can reference a previous package step name, the IIS step requires the package be in the step.

    Is it possible to have a new template parameter type for a Package Name, that still uses the autocomplete that most package deployment steps have? Or possibly a way to pass in the package name to a template while having Octopus retention policies run correctly?

    An error occurred while saving the comment
    Chris Camburn commented  · 

    Any updates on this? While the new 4.X UI is nice, this RFC is 6 months old and would be incredibly useful.

    An error occurred while saving the comment
    Chris Camburn commented  · 

    +1 to the ability to have this function like TeamCity. It would be nice when you have multiple projects all based on a template to update in one place and have that change propagate.

  3. 33 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Product Feedback  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Chris Camburn commented  · 

    I believe this would be best implemented by just allowing nested / hierarchical Project Groups. You could then have different priority groups within a single Project Group that would grant custom reordering, while also granting things like security.

  4. 22 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Product Feedback » Integration  ·  Flag idea as inappropriate…  ·  Admin →
  5. 20 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    6 comments  ·  Product Feedback » Deployments  ·  Flag idea as inappropriate…  ·  Admin →
  6. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Product Feedback » Deployments  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Chris Camburn commented  · 

    Out of curiosity, in what way does the existing 'Skip any package step that is already installed' not cover your scenario? In use it correctly skips package steps we have.

  7. 8 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Product Feedback  ·  Flag idea as inappropriate…  ·  Admin →
    Chris Camburn supported this idea  · 
  8. 165 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    13 comments  ·  Product Feedback  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Chris Camburn commented  · 

    Our use case:
    We have two groups that must approve a release before going to Production, GroupA and GroupB. We would like to maintain the current approval steps when doing a 'Deploy now' deployment, as we need both groups to approve. However, when we want to schedule a deployment for off-hours, it would be nice to have both groups approve ahead of time.

    We are unable to use the workaround of having an 'approval environment' to gate the release prior to going to Production, as we need the approval to happen per deployment, not per release.

    Currently we are looking into writing a custom app that will allow a user to query all scheduled deployments in Octopus, select one for pre-approval, and submit with a comment. This will create a scheduled task to run that will approve the deployment at the specified time. Though not something we'd like to do, it's also better than setting up the VPN and logging in at 2am to approve.

    I envision this enhancement would function similar to how scripts can be run prior to package download. Select an option to "run prior to scheduled deployment." If selected, it will leave the 'deploy now' functionality as-is, but will change the 'deploy later' to allow approval anytime before or during the scheduled deployment.

    Chris Camburn supported this idea  · 

Feedback and Knowledge Base