3 ms·

I agree that writing a ruby script is tempting. Where I disagree with you is that, when you have an organisation of 100s of devs, these scripts become tech debt

I agree that writing a ruby script is tempting. Where I disagree with you is that, when you have an organisation of 100s of devs, these scripts become tech debt. You need to have standard operating procedures delivered via one platform, that's when rundeck et al plays an important role.

chillfox 4y ago
Never have been able to get management buy in for automation. I even had one manager tell me that there was value in having someone do it manually instead of automatic, I suspect part of their pay or career progression was based on the size of their team.
- debarshri 4y ago
  That is precisely what I mentioned in my first post. Activating the customer and getting them to value is the biggest challenge these frameworks have. It is hard to buy into a framework from get go.
  - chillfox 4y ago
    So part of the problem from a sysadmin/developer perspective here is that these automation solutions are too difficult/time consuming to setup on the side and prove their value to management. They basically can’t start as a one or two person on the side initiative and then grow the way other technologies like introducing version control and CI can.
    - gjvc 4y ago
      They basically can’t start as a one or two person on the side initiative and then grow the way other technologies like introducing version control and CI can. They absolutely can. Find a spare host or create a VM. Write a shell script to run docker, or much better, use "docker compose" to create the setup. Have it run on the quiet for a while and get familiar with it, a little more every day, before using it in production. It's crucial that you are confident about using it, so that when you come to sell it to anyone else, your confidence transfers to them. (Sales, in large part, is about the transfer of feeling.) Once you have got the deployment and backup/restore, and tool-specific critical procedures clear in your mind, you're ready. It's not a five-minute job; it's about demonstrating your strategic value to management by getting out of the toil loop. But, to be clear, if you feel you don't have the backing of anyone about such things, you certainly have my sympathy. The best way I have found out of the mire is to work on a workflow (create/destroy, backup/restore, LDAP integration) a little a day, until it's there, and then suddenly, your work put in over the days and weeks will be an overnight success. Good luck!
      - chillfox 4y ago
        The competition is cron and a folder of scrips which provides a productive result from day one. I am not in an ops role at the moment, but in the past nothing has been able to beat cron. And the main reason is the time required to get automation tools up and running.
        gjvc 4y ago
        You missed the point of my reply, and simply repeated your position.

chillfox 4y ago

Never have been able to get management buy in for automation. I even had one manager tell me that there was value in having someone do it manually instead of automatic, I suspect part of their pay or career progression was based on the size of their team.

debarshri 4y ago
That is precisely what I mentioned in my first post. Activating the customer and getting them to value is the biggest challenge these frameworks have. It is hard to buy into a framework from get go.
- chillfox 4y ago
  So part of the problem from a sysadmin/developer perspective here is that these automation solutions are too difficult/time consuming to setup on the side and prove their value to management. They basically can’t start as a one or two person on the side initiative and then grow the way other technologies like introducing version control and CI can.
  - gjvc 4y ago
    They basically can’t start as a one or two person on the side initiative and then grow the way other technologies like introducing version control and CI can. They absolutely can. Find a spare host or create a VM. Write a shell script to run docker, or much better, use "docker compose" to create the setup. Have it run on the quiet for a while and get familiar with it, a little more every day, before using it in production. It's crucial that you are confident about using it, so that when you come to sell it to anyone else, your confidence transfers to them. (Sales, in large part, is about the transfer of feeling.) Once you have got the deployment and backup/restore, and tool-specific critical procedures clear in your mind, you're ready. It's not a five-minute job; it's about demonstrating your strategic value to management by getting out of the toil loop. But, to be clear, if you feel you don't have the backing of anyone about such things, you certainly have my sympathy. The best way I have found out of the mire is to work on a workflow (create/destroy, backup/restore, LDAP integration) a little a day, until it's there, and then suddenly, your work put in over the days and weeks will be an overnight success. Good luck!
    - chillfox 4y ago
      The competition is cron and a folder of scrips which provides a productive result from day one. I am not in an ops role at the moment, but in the past nothing has been able to beat cron. And the main reason is the time required to get automation tools up and running.
      - gjvc 4y ago
        You missed the point of my reply, and simply repeated your position.