I'm working on a project that has frequent changes on the database and the implementation layers. I was releasing both the code and the database under the same release version, but since the database changes are more frequent than the core implementation, I'm thinking of separating their release/plan.
Is this the normal way to do it?
-
2@Yehia, Welcome to the Site! It would help people answer your question if you edited your title to focus on the release plan itself (e.g. "Different Release Plan for Database and Implementation Layer") and give a little more information about the team working on the project. Are you working alone or are other people on the project? Who is the "client" on the project and do they have any requirements on the timing of the release plan?Mark Phillips– Mark Phillips2011年05月30日 14:40:00 +00:00Commented May 30, 2011 at 14:40
-
Maybe a question to SO instead of PM?Tiago Cardoso– Tiago Cardoso2011年05月30日 18:22:24 +00:00Commented May 30, 2011 at 18:22
-
Actually, I was thinking more along the lines of Programmers SE. Stack Overflow is for programming questions that include lines of code whereas Programmers SE is more about questions that are subjective, like this one, which really has no right or wrong answer.jmort253– jmort2532011年05月30日 18:25:53 +00:00Commented May 30, 2011 at 18:25
-
@jmort253 It should be fine for Programmers. Feel free to migrate.Adam Lear– Adam Lear ♦2011年05月30日 22:02:23 +00:00Commented May 30, 2011 at 22:02
-
yea i'm talking about releases so i think it would fit better in the PM website, anyways i got the answers am looking for thanksYehia A.Salam– Yehia A.Salam2011年06月01日 08:49:31 +00:00Commented Jun 1, 2011 at 8:49
2 Answers 2
The purpose of a database is precisely to allow you to keep things separate. So while you don't have to, you can.
The requirement really boils down to what you need, taking into consideration what the best method is to save time wherever practical.
I have worked on a system for which we completely de-coupled database changes from application changes. In fact we made a point of not doing both at once unless necessary (or unless the whole point of the application change was to introduce new capabilities in the database). The reason for trying not to do both at once was to minimise risks of anything going wrong and needing to reverse the installation. The more you change at once, the higher the risk. But that was Air Traffic Control, so we were careful. It all depends on your own circumstances and end user requirements.
The way we resolved versioning is that each database version was also tagged with the application version. Our application versions were such that we knew just by looking at the version numbers whether the database was compatible or not (i.e. major versions were DB changes, minor versions within a same major version were all DB compatible). No matter what your scheme is, you need one that is easy to read & track.
If it works for your system then there's nothing wrong with having separate release plans for the database and the application.
However, it might make things difficult when it comes to ensuring that you get compatible versions of the database and application. You'll have to maintain a list of which version(s) of the database are supported by which version of the application. It's far simpler to have the same version number for both. Then all you need to do is check that they match and you know that they'll work together.