5 ms·

Where do you keep your configs then? For some of my projects I maintain a separate Ansible playbook repo and most of my configs/templates in it. I also checki

Where do you keep your configs then? For some of my projects I maintain a separate Ansible playbook repo and most of my configs/templates in it. I also checkin my Pods directory for my iOS projects. I know there is debate around this but it has been the least painful option for me working on a team.

dvanduzer 11y ago
When you're running a SaaS business, your configs are your code in many cases. Version control is incredibly important for scaling operations. To keep things manageable at scale, you also need to separate concerns properly. But this just means you shouldn't do things like have your configuration API refer to its own repository to configure itself. edit: CocoaPods in particular is a weird artifact that I suspect will go away now that iOS is supporting dynamically linked frameworks.
- seivan 11y ago
  Some of us like CocoaPods offering source dependencies instead. Makes it easier to learn, debug and fork. That being said, the quality has gone downhill. Besides it's easier to manage your dependency in a Podfile than submodules.
  - dvanduzer 11y ago
    Managing your dependencies on external bits is distinct from someone upstream dealing with the packaging and distribution of those external bits.
    - seivan 11y ago
      Those bits won't change that much over time once the project becomes stable. It's not much of an issue.
seivan 11y ago
There is some massive pain of having Pods checked in in the beginning of a project, but once you get more stable it's alright.
wtbob 11y ago
> Where do you keep your configs then? In a different git repo. In my mind, the developed code and the deployed environment are, or should be, quite separate. I've been pretty successful with this in the past, and when I've been on teams which violate it…suffering has happened.
EvanPlaice 11y ago
Application config != environment config. Configuration for setting up your application will be checked in as usual. Configuration to switch modes (ex testing/production) as well as config for sensitive information (ex auth credentials) should never be checked in. As an example, there was a news story that popped up lately of a guy who accidentally published his AWS private key to a GitHub repo and ended up being charged for thousands of dollars of usage when somebody saw it and decided to use it for malicious means. Same goes for testing/production. There's no excuse for displaying debug info to users. You're basically giving hackers a fast lane to fuzzing and exploiting your server.

dvanduzer 11y ago

When you're running a SaaS business, your configs are your code in many cases. Version control is incredibly important for scaling operations. To keep things manageable at scale, you also need to separate concerns properly. But this just means you shouldn't do things like have your configuration API refer to its own repository to configure itself. edit: CocoaPods in particular is a weird artifact that I suspect will go away now that iOS is supporting dynamically linked frameworks.

seivan 11y ago
Some of us like CocoaPods offering source dependencies instead. Makes it easier to learn, debug and fork. That being said, the quality has gone downhill. Besides it's easier to manage your dependency in a Podfile than submodules.
- dvanduzer 11y ago
  Managing your dependencies on external bits is distinct from someone upstream dealing with the packaging and distribution of those external bits.
  - seivan 11y ago
    Those bits won't change that much over time once the project becomes stable. It's not much of an issue.

seivan 11y ago

There is some massive pain of having Pods checked in in the beginning of a project, but once you get more stable it's alright.

wtbob 11y ago

> Where do you keep your configs then? In a different git repo. In my mind, the developed code and the deployed environment are, or should be, quite separate. I've been pretty successful with this in the past, and when I've been on teams which violate it…suffering has happened.

EvanPlaice 11y ago

Application config != environment config. Configuration for setting up your application will be checked in as usual. Configuration to switch modes (ex testing/production) as well as config for sensitive information (ex auth credentials) should never be checked in. As an example, there was a news story that popped up lately of a guy who accidentally published his AWS private key to a GitHub repo and ended up being charged for thousands of dollars of usage when somebody saw it and decided to use it for malicious means. Same goes for testing/production. There's no excuse for displaying debug info to users. You're basically giving hackers a fast lane to fuzzing and exploiting your server.