Chris Camburn

My feedback

  1. 17 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General » Deployment features  ·  Flag idea as inappropriate…  ·  Admin →
    Chris Camburn shared this idea  · 
  2. 833 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  31 comments  ·  General » Deployment features  ·  Flag idea as inappropriate…  ·  Admin →
    Chris Camburn supported this idea  · 
    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.

    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?

    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.

    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. 135 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  General » Setup/administration  ·  Flag idea as inappropriate…  ·  Admin →
  4. 98 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    13 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Chris Camburn commented  · 

    My specific use case is to not just run something once, but to have it run on one tentacle from a pool of tentacles. We have a handful of server-intensive processes that can be run from any server, but must only be run once. What we'd like to do is have a handful of tentacles with the same role, and each deployment would select one tentacle with that role and run the steps. That allows us to do something similar to TeamCity build agents, and offload the work on the first available tentacle.

  5. 70 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  6. 40 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General » Integration  ·  Flag idea as inappropriate…  ·  Admin →
  7. 36 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  General » Deployment features  ·  Flag idea as inappropriate…  ·  Admin →
  8. 92 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  General » Deployment features  ·  Flag idea as inappropriate…  ·  Admin →
  9. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General » Deployment features  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  10. 556 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    18 comments  ·  General » Integration  ·  Flag idea as inappropriate…  ·  Admin →
    Chris Camburn commented  · 

    Even with octo.exe export for deployment processes, that doesn't provide the ability to recreate the entire server. TeamCity has direct source control integration, so that in the event that something should happen to my server, I can link a new install to source control and recover every bit of configuration.

    The other two (smaller) advantages of this are the ability to edit configuration outside of the UI by making changes directly in source control, and the ability to accurately track all changes made. The audit log in Octopus is difficult to use when tracking small changes to a deployment process. Source control integration would make this simple.

  11. 14 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Chris Camburn supported this idea  · 
  12. 380 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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