1

I'm starting to question if I'm following best practice on my Git strategy between master and dev since deployment is not as straight forward as it seems it should be.

I have a master and dev branch that have some environmental differences. In most places where it is a configuration difference (i.e. connection string, app setting, etc.) I have been able to abstract these different into environment configuration files which live outside of Git. When switching from master to dev, the developers on the team copy and paste in the correct environment configs and everything works correctly.

However, there are some places where the code itself differs between master and dev. The most concrete example of this is within the Ninject (DI) configuration file which differs between using the production Email Service and the development one so customers are never accidentally emailed.

We've considered using the #if DEBUG preprocessor but this wouldn't protect against a developer running the dev branch in "Release" mode.

This difference in code across branches becomes difficult to manage when merging dev into master because each time we find ourselves manually ensuring the master code is never overwritten. To aid in this we ended up creating a "merge" branch which is already set up with the production commits and ignores the conflicting dev commits.

The issues becomes keeping all these branches in sync and merging / issuing pull requests in the correct order to ensure the correct code is merged.

If possible, can someone suggest a better "strategy" on managing these branches so deployment is as simple as merging dev into master?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Stringer Bell
  • 265
  • 1
  • 4
  • 13
  • First of all, this is probably more fitted to programmersexchange, rather than stack. Secondly, your code should NEVER be different between production, test and dev (that is, of course, once it has been released and the same version runs across all three - typically prod will be the oldest, test newer and dev the newest). The idea that you have a different service for prod is terrifying. how do you test it? how do you ensure if it still works? With most e-mail services (SMTP, AWS SES, sendgrid etc.) you could easily use a different cred set for different environments. – zaitsman Dec 04 '17 at 01:25
  • You should also write some code into whatever is sending e-mails to avoid sending it to real customers (if you have a situation where real customer data lives in dev/test) -> for this, add something like `Environment` to your settings file (whatever that might be) and have your CI update that on deployment. – zaitsman Dec 04 '17 at 01:26
  • For the config/settings files, you can also manage them in `.gitignore`. – Marina Liu Dec 04 '17 at 05:58
  • @zaitsman i would strongly disagree with your first comment. Using a dev specific dependency injected service doesn't hurt test-ability. If we use sendgrid in production but want to use mailtrap.io for development purposes i don't see how that's "terrifying". As for your second comment, i rather like that. What you're suggesting is to keep the environment in the config file and read that instead of using the debug flag.Post that as an answer? I would merge approaches and have the SMTP service switch out based on the environment variable but the source between both would be identical. – Stringer Bell Dec 04 '17 at 17:55
  • @MarinaLiu-MSFT - yes we use .gitignore for all the *.config files. – Stringer Bell Dec 04 '17 at 17:56

1 Answers1

0

For configuration files, you need to maintain several value files (value.master, value.branch1, ...) and one template file per config, in order to generate automatically the actual config file.
See "Do not overwrite config file on Azure using GIT": it uses a content filter driver.

For code, if you can, maintain different execution paths within the same code in order to avoid managing merges.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250