On Fri, 05 Sep 2008, Mike McGrath wrote: > So as many of you have seen in the commits lists, the staging environment > is coming along and getting built. I've hit a policy issue and so I > thought instead of just doing this in a black hole. I'd discuss it. > > The way I see it there are two ways to do staging environments. For those > of you unfamiliar with staging the general idea is to have an environment > as close to production as feasible. > > 1) use identical configs with only minor changes and use /etc/hosts to > fake things to point where you need them. Not always possible but > generally good where you can do it. > > 2) use different configs in production and staging. The differences being > able to redirect things, using different usernames, passwords, hostnames, > etc. > > Each has pros and cons. Right now I'd like to do 1) but I don't think its > possible. 2) is going to require a lot of focus. For example... we won't > be able to just git merge from staging to production as we could with 1). > > Security's only an issue in that we don't want people making changes to > production data from staging and vise versa. The same people will have > the same access to both of these environments without exception. > > I'm going to continue to think about this. I've had staging environments > in the past. Both went with option 2). But still. I'd like to hold this > discussion so discuss. What I've done is #2, but with software that accepts a second config file that overrides the first. The first config is the same between production and staging, and the staging specific config is in the second file. That way you can keep your staging settings from accidently getting migrated to production. This works best if you only have a small amount of changes between staging and production and if your software supports it. Maybe puppet templates for all the config files that differ would be the best way to handle f-i's needs? _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
