0

I have a bash script that I need to run on multiple (personal) machines, using systemd timers. While largely similar, there is some functionality in these scripts that I need enabled on some machines, but not on others.

Right now, I'm using git branches to manage the scripts and timers. This seems to be convenient and working fine, but I'm wondering if it's a recommended practice.

While unlikely, I do see a potential source of problems (human introduced error): checking out the wrong branch on a machine.

My questions:

  1. Is this enough of a concern to avoid using git?

  2. Are there other potential problems I may have not considered?

  3. Is this method recommended for managing scripts and timers on multiple machines? Or am I better off (a) rewriting the scripts to make them more portable and configurable, (b) just having machine specific files, without git branches, (c) something else?

  • It's ok if you can manage it? If would keep a production branch with them all in and have a CI server deploy the correct one to the server etc – Matt The Ninja Sep 1 '17 at 12:18
  • What does this script do? – gf_ Sep 1 '17 at 12:25
  • @gf_ It's a backup script. – dwrz Sep 1 '17 at 12:57
  • 1
    Hm...regarding your third question: Maybe a look into configuration management would be worth it. – gf_ Sep 1 '17 at 13:22
1

I'm a maintainer of the node-config library, and have lived through some configuration disasters before finding a successful model.

I recommend keeping all the configuration in a single branch.

Consider some update you want to make that could be done with find-and-replace across your files. If all the files are in the same directory, this is an easy. If the change affects work on other branches, then you have to check out every branch to make the change on each branch.

In node-config, we use an environment variable to set the "environment", like "production" or "development" and another to set the "instance". It also allows configuration based on the hostname of the current machine.

The result is a single codebase with a single, centralized configuration. The code is configured to behave differently based on environment variables and the hostname-- the code itself is exactly the same between environments and hosts.

In your case, you could have your bash framework source one or more files based on the hostname. Thus your code could be exactly the same everywhere, but would still behave as needed on different hosts.

You might even run all your timer actions on every host, just have them do nothing on some hosts.

  • Thank you. Very insightful and the answer/approach immediately makes a lot of sense. – dwrz Sep 1 '17 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.