i was reading some posts about SDF and gitflow the...
# suitescript
n
i was reading some posts about SDF and gitflow there's something i'm missing
how does one use production as master and sandbox (or dev account) for dev branch? wouldn't each essentially need their own independant gitflow structure? i.e. a master for sandbox and a master for prod?
ideally i think i want to use SDF acct customization projecs. 1. to get as many non-script objects as possible in source control 2. have a decent dev flow that is scaleable, etc
e
It's very difficult to keep source control exactly in line with the state of a particular environment, especially if you have a team of developers actively uploading/testing code. Rather than mirroring the exact state of an environment, your branches dictate well-known states of code.
master
is always stable, production-ready code and should nearly always match Production.
develop
is code that has been merged and tested in conjunction with other related features for the upcoming release.
feature
or
bugfix
branches are either WIP or code that has only been tested in isolation. You use that information to know what you can upload to which environment.
Same goes even if all you're doing is keeping Customization Objects in your projects and no code. If there are several administrators actively changing different customizations, your source control is likely to fall behind and won't exactly match the state of any particular environment.
n
so you would have a development branch pointed at which instance?
remember this is all about SDF. So after one creates something production ready it seems that there are so many potential dependencies that even with multiple devs (which we have for customization items only not scripts) you would really have to deploy to a master branch that incorporates all (the types of) objects in the account
^^ no? @erictgrubaugh. otherwise could you not easily end up with a master branch that can't even be deployed?
e
I don't point branches at any particular instance
If I want to deploy the latest stable code/customizations, to whatever instance, then I know to deploy
master
If I want to deploy the next staged release, to whatever instance, I deploy
develop
, or perhaps a separate
release
branch that I typically make
but there is not a 1:1 relationship between a branch and an environment in any of my repositories