July 1, 2014 at 9:15 pm
Comments posted to this topic are about the item The myth of the ‘shared development model’
Best wishes,
Phil Factor
July 2, 2014 at 12:28 am
Development environments should be as simple as you can get away with but not simpler (to deliberately misquote Einstein).
All code should be under source control at any point it is released (even internally), to be worked on by multiple team members (under any guise) or passed on between team members. Other restrictions due to local best practices may apply.
That is my opinion. Others will have differing ones from their different experiences, environments and requirements.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 2, 2014 at 3:43 am
I think even those simple requirements would tax many shops to be fair Gary. I think it's a reasonable summary of minimum requirements - I don't think it's sensible to say there is anything too much you should definitely do - circumstances are all different.
I think it interesting to hear Mr Factor has never reverted SQL code during active development - I was trying to think of when I have done so, and failed. What I have more often used SQL Source Control for is a) checking changes made by other team members b) reviewing what the code was doing at some point in history and why it has been changed to what it does now. Both of these are incredibly useful but not exactly the primary purpose of source control as I originally thought of it, as a developer.
July 2, 2014 at 4:39 am
call.copse (7/2/2014)
I think even those simple requirements would tax many shops to be fair Gary. I think it's a reasonable summary of minimum requirements - I don't think it's sensible to say there is anything too much you should definitely do - circumstances are all different.I think it interesting to hear Mr Factor has never reverted SQL code during active development - I was trying to think of when I have done so, and failed. What I have more often used SQL Source Control for is a) checking changes made by other team members b) reviewing what the code was doing at some point in history and why it has been changed to what it does now. Both of these are incredibly useful but not exactly the primary purpose of source control as I originally thought of it, as a developer.
In my opinion, the minimum requirements should not be too taxing for any professional software developer (including database developer) to achieve. Of course, source control could be achieved by saving it to a network location as specified in the editorial. However, I maintain my stance that this is the minimum.
Everyone is entitled to disagree. My opinion is just that: my opinion.
🙂
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 2, 2014 at 12:26 pm
Wow, I'm just amazed that this is such a sensitive topic. As the others have said, each organization has its own approach. As long as it works. But it must work, if not then its time to improve.
The more you are prepared, the less you need it.
July 2, 2014 at 2:06 pm
Friendly, passionate debate but with mutual respect. I am quite happy to disagree and be disagreed with. Where is the value of debate if there isn't point and counterpoint?
Right, ladies and gentlemen?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 4, 2014 at 2:44 am
Sorry folks - wasn't trying to be contentious - just reflecting on the poor state of some shops I've encountered. I was pretty much agreeing with you Gary.
July 4, 2014 at 4:01 am
call.copse (7/4/2014)
Sorry folks - wasn't trying to be contentious - just reflecting on the poor state of some shops I've encountered. I was pretty much agreeing with you Gary.
No worries. It's all just healthy debate 🙂
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 15, 2014 at 1:30 pm
Regarding the "central/shared" database: We have scripts that do the nightly build process, and do a database install to a shared server, with the extra twist that the build number is part of the database name (as suffix). This central database can be used by a developer who doesn't want/need to install each build locally every day. We don't view the central install as "inviolate", they get thrown away after a while; but they let a developer compare a query on their environment versus "how did it work in the build yesterday/week ago/etc."
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply