I suggest you...

Version Control of deployment scripts

In the Continuous Delivery book, Jez wrote that your deployment scripts should be in source control. After creating some pretty elaborate powershell scripts for Octopus, I have to agree. Losing those scripts or having them damaged would be pretty painful.
I understand Octopus has backups, but it would be better to be able to get back to a previous version or see where the script had changed. Since we use GIT, I would be completely satisfied if GIT integration was all that you supported. :) I hope this is helpful. Thanks.

431 votes
Vote
Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Dave Welling shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

33 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
Submitting...
  • Mark Evans commented  ·   ·  Flag as inappropriate

    Agreed.

    The logic should follow very much the same approach Ansible Tower has taken w/ Ansible. Or how Amazon Opsworks has for Chef.

    Let me give you a git repo with all scripts. You should define a folder structure.
    From within Octopus Server it should always do a checkout of repo before a deploy.

  • Peter Karaganis commented  ·   ·  Flag as inappropriate

    I really like the Team City approach to version control for builds. I think something like that would be a giant leap forward to implementing a version control solution for deployments.

  • Sam “Betty” McKoy commented  ·   ·  Flag as inappropriate

    I think the entire release configuration should be able to be read from the NuGet package. That way it's independent from source control but can be stored in source control if I choose.

    The editing experience won't be as nice as I'd be editing a JSON (or similar) file instead of using a GUI, but has a lot of other merits.

  • Chris Barr commented  ·   ·  Flag as inappropriate

    Maybe I'm missing something, but how is import/export the same as having version control on all the build steps? Looks like this is a manual process... yea, we could export and manually put them into source control - but we'd need to do this automagically everytime we change something? Is there any plans to have all build steps just auto version controlled?

  • Wayne Brantley commented  ·   ·  Flag as inappropriate

    Would have been better to just introduce Git/Mercurial/tfs repository support - and then we could just point OctoDeploy to our repo....bam done...

  • Bart Read commented  ·   ·  Flag as inappropriate

    I'd add a big +1 for this although, as others have said, not just for git. I run across a reasonable amount of TFS and svn in the wild as well, so think it would also be worth supporting at least those two.

  • Jon Kennerly commented  ·   ·  Flag as inappropriate

    Would a GIT repository be the only option? Those with the "main code line" in TFS or other might not want to utilize multiple SC providers.

  • John Crim commented  ·   ·  Flag as inappropriate

    I would recommend that you support exporting + importing a developer-readable config file for each project. And probably separate the variables into another file just to make them really easy to track.

    Even better would be the ability to make the versioned project configuration the authoritative source of project configuration. It would be clunky to require a manual export + commit each time a config setting or variable is changed, if you want your vcs history to match the history of the project configuration.

  • John Crim commented  ·   ·  Flag as inappropriate

    I think it's important that the entire project configuration, and optionally properties (excepting password properties - passwords shouldn't go in version control), should be commitable to source control. Then you can track all changes to the project in a single place.

    Teamcity is now supporting committing build configuration to source control.

    The absence of this is a major drawback from using Octopus relative to our current deploy system.

  • D Lemos commented  ·   ·  Flag as inappropriate

    The most single important feature to implement on a new major version.

  • Peter Goodman commented  ·   ·  Flag as inappropriate

    We are really keen to see this feature. We've identified this as one of the major areas of concern for us. TeamCity has a pretty good approach to this although at times it can be hard to attribute the reason for a change without commit messages.

    SQLite seems like a sensible choice. The Raven indexing issues we have had after an export+import migration are very concerning.

  • Martin Jæger commented  ·   ·  Flag as inappropriate

    This would be so awesome.
    Transparency in configuration-changes is key.
    Would you also put variable-values in git? Or store these in RavenDB to better control sensitive data like passwords.?

  • Anonymous commented  ·   ·  Flag as inappropriate

    This would be handy if it just had an export option so you can save them to any kind of repository not just git, export process steps alone would be handy right now.

  • Dag Nygaard commented  ·   ·  Flag as inappropriate

    I support the suggestion that deployment scripts should be managed in a way that administrators may version control current process steps in a configuration file, for instance OctopusDeploy.config.xml.
    - I can then use whatever version control system I prefer.
    - I can retrace my steps (if I use the version control system as intended)
    - I can move OctopusDeploy from one server to another much easier.

  • Ryan Rousseau commented  ·   ·  Flag as inappropriate

    We currently put our deploy scripts in our source control with the projects we deploy. When we build the nuget package, we just make sure that it is copied into the correct folder as Deploy.ps1

  • sean commented  ·   ·  Flag as inappropriate

    Would love to see this! Improved git support as a backend would be awesome.

    One of they key principles introduced in the Continuous Delivery book is to 'store absolutely everything in version control'. Having Octopus configuration and scripts outside of that is less than ideal given it's role in application delivery.

  • Justin commented  ·   ·  Flag as inappropriate

    Ive recently been working on a POC for deploying Sql scripts and its not ideal to paste text into the script block or create a nuget package with a ps1 file. This feature would convert me more to using Octopus for production releases in our company (250+ devs).

  • Job Vermeulen commented  ·   ·  Flag as inappropriate

    @Paul, I don't think your latest post describes the complete solution.
    I care more about the steps with their settings.

    That's something different then a attachment from Git.

← Previous 1

Feedback and Knowledge Base