Blair Paine

My feedback

  1. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  General » Setup/administration  ·  Flag idea as inappropriate…  ·  Admin →
    Blair Paine shared this idea  · 
  2. 241 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Blair Paine supported this idea  · 
    Blair Paine commented  · 

    Would love to see this. We need to execute steps under different accounts in order to take certain actions. It's less secure to give one account rights to everything needed.

  3. 31 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Blair Paine commented  · 

    Our business has a requirement to have all PowerShell scripts signed. This policy is forced by security software installed on deployment targets. Unfortunately without this capability we can no longer use Octopus Deploy as an enterprise application.

    Blair Paine supported this idea  · 
  4. 430 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    21 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Blair Paine commented  · 

    Our environments screen is getting very ugly very quickly as we add more and more deployment targets. We currently have over 4000 potential deployment targets in our environment across multiple environments. Groups would allow better filtering on the environments page and in other places.

    It would be fantastic if:
    - We could filter on various attributes including tenant, role, domain, connectivity status etc

    - On the tenants screens we can see which deployment targets have been assigned.

    - You could apply tags to deployment targets which can then be used to filter much like tenant tag as suggested here - https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/5782511-allow-tagging-environments-with-keywords

    - More granular restrictions could be placed on which groups of deployment targets can be seen by certain teams/users.

    Blair Paine commented  · 

    It would be great to be able to group environments in a way that allows a "live" and "implementing" environment. For example, we often create new environments and build them in parallel to existing active environments. We may have an active Production environment and a Production environment being built but not completed/enabled/released yet. Both are considered "production", and I could have a different release deployed to each.

    When deploying a release, it should be possible to select if I am to deploy to the implementing production or the live production. If it's live production then there may be additional checks or steps.

  5. 28 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 →
    Blair Paine supported this idea  · 
    Blair Paine commented  · 

    Recreating a release also puts the list out of order. Releases may need to be recreated because of the snapshots feature.

    Allow the any page listing the releases or release drop downs to be sorted by the release version number rather than the assembled date. If simple enough, you could also allow releases to be sorted by other properties.

    Our problem/issue is posted here:
    http://help.octopusdeploy.com/discussions/problems/50250-release-ordering-not-by-release-number

  6. 44 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  General » Deployment features  ·  Flag idea as inappropriate…  ·  Admin →
    Blair Paine supported this idea  · 
    Blair Paine commented  · 

    I agree with this. It shouldn't be difficult to implement, it's just an extra field and can use the same description fields as other screens.

    Rather than hard coding in some text I may just provide a link to documentation explaining that step i.e. in Confluence.

  7. 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 →
    Blair Paine commented  · 

    Scripts, configuration, variables, every input should be able to be stored in source control and fully audited i.e. GIT. We're looking to integrate with etcd or consol to obtain key/value pairs of variable information from JSON/YAML configs in GIT and share across all of our pipeline via the API. If anyone changes a configuration we'll know when it was changed and who changed it and for what reason.

    I don't want my variables and configuration data for an entire pipeline tied to just Octopus. Octopus is a key part of our delivery pipeline but I don't believe it should own the inputs to make it work.

    Voted up after posting here:
    http://help.octopusdeploy.com/discussions/questions/9658-anyone-using-git-and-consul-with-od

  8. 30 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Blair Paine supported this idea  · 

Feedback and Knowledge Base