Michael Noonan

My feedback

  1. 14 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 →
    Michael Noonan commented  · 

    Just thought I'd point you to a recent discussion on snapshots so you can add your voice to the conversation: https://octopus.com/blog/rfc-removing-snapshots Hope that helps!

  2. 28 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 →
    Michael Noonan commented  · 

    Interesting idea. Just confirming, this is to create safety, so you don't accidentally deploy 2.x into any machine(s) that are designated 1.x?

    Our current design, like you mentioned, is to create a new Environment and Lifecycle to provide that safety. One reason for this is there is an existing mapping from Machine -> Environment -> Lifecycle -> Project -> Channel, because Channels "belong" to a Project.

    So when you want to restrict a Machine to one (or more?) specific Channels, we would need to map Machine -> Project -> Channel, which could leave room for confusion with the other potential mappings, like Roles.

    I like the idea, that when you're creating a new machine, you know the purpose you intend for that Machine, and it's a good idea to stamp that Machine with its "purpose". (We are allowing something similar for multi-tenancy - see https://octopus.com/blog/rfc-multitenancy-take-two#deployment-targets-and-accounts)

    Could you have a think about your situation and let me know how you would expect this to work, perhaps with a mockup which would really help illustrate!

  3. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  General » Deployment features  ·  Flag idea as inappropriate…  ·  Admin →
    Michael Noonan shared this idea  · 
  4. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General » Setup/administration  ·  Flag idea as inappropriate…  ·  Admin →
  5. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General » Setup/administration  ·  Flag idea as inappropriate…  ·  Admin →
  6. 218 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  General » Setup/administration  ·  Flag idea as inappropriate…  ·  Admin →

    We have recently made good progress on getting Tentacle running on Linux via netcore and expect it to be available in the next couple months. https://github.com/OctopusDeploy/Issues/issues/3596

    As for Octopus Server on Linux, we have also started working on this effort however the current focus is for internal use for running Hosted Octopus. There are some additional complications that come with running Octopus on Linux particularly in the context of “run on the server” and s a result I wouldn’t expect a version of this to be available until mid-year at the earliest.

    Most of our other additional tooling and libraries like Calamari are now available to be run on netcore and run on Linux.

    Michael Noonan commented  · 

    Porting Tentacle/Calamari to .NET Core would enable deployments on Windows Nano Server also.

Feedback and Knowledge Base