6 Responses

  1. Andy Konecny
    Andy Konecny at |

    The whole Dev vs Ops thing just doesn’t exist in so many shops, because so many don’t have any Dev involved. While most who script might be in shops that have other scripters and/or coders to share with, there are more shops out there with just one who scripts. As someone who doesn’t come from a coding background as do most of the techs at those small shops (Civil Engineering for me, PC support for so many others now days), I find those version control systems to be so painful to get my head around because of the built in assumptions. I am continuing to pound at is as I also am building up my bash.sh skills as I do see the value in sharing with others out there, but it is certainly harder than it needs to be. This is a great opportunity for someone to try and write up using something like GitHub for the standalone non-programmer such as a bash.sh or powershell writer. You’ve made a good start on this, it just isn’t yet enough to bring the effort cost low below the threshold for many. I’m still not yet where I need to be to write it up myself, so I am still looking.

    Reply
  2. Rich Hintz (@rjhintz)
    Rich Hintz (@rjhintz) at |

    I got here using the search terms: “networking version control,” suggested from some comments in Chris’s podcast Datanauts 4, “Provisioning.” Version control is MIA in many, maybe most, shops once artifacts leave Dev and is really rare in the Networking silo, so it’s good to see this discussion.

    Andy’s point above about getting Dev involved is really on point since, as a minimum, it means that there’s a hope of getting commonality in policies and use of version control in an organization, which is key in turn to optimizing continuous integration/deployment. I’m guessing that the times Devs and Networking folks interact directly professionally is close to zero.

    As far as the version control system itself, it’s probably not worth a months long project to select a version control system. If Dev, and by extension the rest of the organization, isn’t using or converting to Git, and probably Github today, they better have a pretty good reason.

    There’s a not so good scenario where Dev is using RCS, Subversion, or a similar older system as version control. Ugh. If that’s the case you might try a conversation about technical debt and see how that goes. If they’re running Mercurial, Gitlab, or something that’s more modern, at least some thinking went into the decision.

    Consider a shop with a test/pilot project or evolving production use of public cloud, perhaps AWS, in addition to their legacy infrastructure. Setting up the IaaS infrastructure supporting the app(s) can all be automated.

    It makes sense from the start to version control everything, especially, as Chris says, to allow for experimentation or, better, test driven development of automation tools, which can and should include networking components. And when Ops starts involving Dev with CI/CD and tools like Puppet, Chef, Ansible, and the like, the Networking people better make sure they’re at the table.

    On the point about Git training, I’ve found the free Github Bootcamp https://help.github.com/ useful. There are good YouTube videos as well.

    Reply
  3. How to Setup and Configure Git Shell for Private Scripting Projects - Wahl Network

    […] past, I’ve blathered on about the need to use a Distributed Version Control System (DVCS) for obvious reasons, while also hinting at my use of GitHub for code aimed at Operations folks. In this post, I’m […]

  4. Using Developer Methodologies to Build Collaborative Operations - Wahl Network

    […] I first wrote the post entitled Why You Should Embrace Version Control for Operational Artifacts, I had no idea that it would spawn an entire series on writing code against RESTful APIs. I began […]

  5. Testing External Pull Requests Before Merging to Your GitHub Repository - Wahl Network

    […] a distributed version control system has been a fun learning experience, especially the collaborative nature surrounding open source […]

Share your point of view!