0

I'm a new developer who is picking up python. I'm currently writing code using python's asyncio or twisted framework to automate the setup of some raspberry pi and servers I got 2nd hand (xen, hyper-v) using SSH, I tried ansible but I prefer writing my own code for learning.

does this fit into software defined infrastructure? if I setup automate deployment of code, is this considered devops?

additionally, I hope to enquire if my intended workflow is considered "devops"?

  • gitlabs
  • automated code testing (tox/travis ci)
  • automated deployment of code to raspberry pi
laycat
  • 111
  • 3
  • 1
    If you prefer, you can also use Salt Stack and ansible which both are based on python. I assume you don't write all your own libraries and will use existing libraries where possible. Why wouldn't you do the same with your configuration management/automation system? Reinventing the wheel every time is ill-advised. And this is a big wheel. – James Shewey Jan 02 '18 at 17:17
  • "I've laid down some gravel in my backyard to make a path. Is that considered infrastructure and can I apply for a federal grant? I don't like to use the industry standard wheelbarrow to carry gravel, but I prefer to make a makeshift one from my son's toy car. Can I call myself a civil engineer?" What are you trying to achieve? Learn a trade? Make a DIY project? Get skilled at the use of buzzwords? It is not exactly clear from your question. – Jiri Klouda Jan 03 '18 at 16:59

1 Answers1

6

if I setup automate deployment of code, is this considered devops?

Sure, automating everything is a big part of DevOps.

I tried ansible but I prefer writing my own code for learning

Now, this is laudable, but using Ansible (or Puppet or Chef or ...) would be "learning" as well. The benefit of using established tools over DIY is that if/when you meet other developers, you have a common toolset to work with. Doing it yourself is nice sometimes as well, but basing a whole software development process on 100% self-written tools (from scratch) is not a good idea, unless you have deeply evaluated the existing tools and consider them all unfit for the purpose.

When your team grows and you encounter a new developer - is it more likely that they already know about Ansible, or that they know about the code you wrote?

Also, the fact that the tools mentioned above do not do their stuff in the "code" directly, but that they have text files which configure them, is important as well. It abstracts the configuration stuff away from actual code, which will be hard to maintain a few years down the road, no matter how good you are.

AnoE
  • 4,876
  • 13
  • 25