Release implementation
-
Hi all, Our project has two teams - Application Production Support and the Development team. Its a reasonably big project (around 50 people). Can anyone suggest the release model and/or how the configuration management should work for the project? If you could explain how it works in any of your projects, maybe we can take a hint from there. Thanks in advance.
-
Hi all, Our project has two teams - Application Production Support and the Development team. Its a reasonably big project (around 50 people). Can anyone suggest the release model and/or how the configuration management should work for the project? If you could explain how it works in any of your projects, maybe we can take a hint from there. Thanks in advance.
-
Virat Soni wrote:
If you could explain how it works in any of your projects, maybe we can take a hint from there.
Just a crazy idea but maybe you could use Google to find things like this[^]
led mike wrote:
Just a crazy idea but maybe you could use Google
Oh you crazy so and so. It's zany ideas like this that make people chuckle. You're mad you are.
Deja View - the feeling that you've seen this post before.
-
Hi all, Our project has two teams - Application Production Support and the Development team. Its a reasonably big project (around 50 people). Can anyone suggest the release model and/or how the configuration management should work for the project? If you could explain how it works in any of your projects, maybe we can take a hint from there. Thanks in advance.
use subversion for your cm tool, you can use it from the command line, or tortoisesvn (windows gui version), or subclipse (eclipse plugin). use trac to track progress, tasks, bugfixes, user docs etc... http://trac.edgewall.org setup subversion and trac on an apache webserver, and you should have no problem. make sure you identify two people to handle all the CM work, and appoint them as your official "build-meisters", set up nightly cron jobs for builds, etc. have two branches a delivery branch, integration branch, and make sure the developers create their own branches when they work on code. set periodic dates for builds, do code reviews and make sure your developers unit test their stuff before checking their code into to the integration branch. test everyones stuff together using the integration branch...make corrections, retest, repeat until you have something good...then merge it into the deliverable branch. reset the integration branch from that point on the delivery branch... and repeat... make sure the developers continually grab the latest from the integration branch if their stuff doesn't make the deadline or cut... they need to always play with the current stuff.. kind regards,
David