Options
Development Environment
jdw
Posts: 2
We're a development team of four, with two consultants who contribute to the project from remote locations. We've got a SQL back end. Our current setup is that we are all developing against the same back end and we'll use Redgate products to build the scripts to upgrade old versions of our database to a state that matches this development back end, once we make the release build.
In general, does it make sense to use a setup like this, or should each developer have a separate back end for doing development work?
Thanks much for any feedback.
Jeremy
In general, does it make sense to use a setup like this, or should each developer have a separate back end for doing development work?
Thanks much for any feedback.
Jeremy
This discussion has been closed.
Comments
Each morning the first person in uses SQL Compare to reysnc the changes once they're stable and gets the new code from source gear so of course it matches the database schema.
We also then push the changes to a test server where the tester is running things so generally it goes something like this...
1. SQL Compare Richard to Steven
1.1 Pull changes from Steven to Richard
1.2 Push changes to Steven from Richard
2. SQL Compare Richard to Test System
2.1 Push changes from Richard to Test System
3. SQL Compare Richard to Live System
3.1 Save snapshot of richard into source control ( can use Scream to compare history )
3.2 Save migration script into source control
3.3 Cancel migration
I would imagine you could use the system in this way and it could work quite well. The danger doing it with one backend is that if somebody makes a breaking change it breaks everybodies development until they check in their code and all the developers get it.
Our method also relies on regular updates so the synching back and forth from Richard to Steven is easy to resolve.
Hope this helps.
Project Manager
Red Gate Software Ltd