Re: How do you TEAM Code?
This WebDNA talk-list message is from 2004
It keeps the original formatting.
numero = 58129
interpreted = N
texte = The WebDNA CMS is intended to be used by a team of developers withcheck-in, check-out, locking, workgroup access security model, etc.John is right in that any CMS/CVS isn't really intended for databasechanges, except in the sense that during a development cycle, you mayhave 'dev' versions of the databases where you are maintaining controlof the synchronization of code changes with DB schema changes. Theactual content of the DBs within a CMS/CVS is just test data at thatpoint. Once you move into a production deployment scenario, youcertainly wouldn't be deploying DB's from a CMS system ... Any DB in theCMS would be strictly as a test mule for validating code changes versusschema changes.With the WebDNA CMS, you can put in place some controls that will helpyou compartmentalize the development between the individual coders ...Create a separate workgroup for each developer, then set the workgroupprivileges such that each developer can only modify a subset of the codethey are directly responsible for. On any folders/files where thereneeds to be shared modifications you grant access across multipleworkgroups. For those areas that need careful integration, e.g., whencode and DB schema changes need to be migrated together, set up anapproval process with someone assigned the administrative responsibilityto review and control the rollout of those changes to the staging area.>From a logistical process with any CVS tool you choose ... On priorlarge development projects (20+ developers), I've always maintained thatif a developer checks something in, it had better be well unit testedand not break the overall project 'build' ... often due tointerdependencies with code written by other team members. This forcesdevelopers to think about any collaborative 'merges' they may need to dowith other team members prior to performing a check-in ... Or if acheck-in is going to fundamentally change some foundation object thatwill impact everyone else, this is broadcast in advance so everyoneknows to "get latest" and make their changes right after a new COMobject, DB schema, include file, etc., becomes part of the most recentversion in the CMS/CVS system. I've even pushed this to the point ofhaving automated nightly 'builds' of the latest version of everything inthe CMS/CVS ... If something broke the next morning due to someone'scheck-in, the responsible developer was tagged with fixing it ASAP.Even if a project was only 25% complete, that 25% worked every morningor someone got paged. From a QA perspective, we obviously didn't try todo full QA on every daily build ... We just maintained the teammentality that we always kept the most recent set of check-ins in astate where you 'could' perform QA at any given moment on the X% of theproject that was functionally complete.Phil B.-----Original Message-----From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com] On Behalf OfNitai @ ComputerOilSent: Friday, May 28, 2004 8:37 AMTo: WebDNA TalkSubject: Re: How do you TEAM Code?Yes, I mean many developers working with the "same" code.So if I understand you right, we create a branch for each developer.He/She works within that branch and then when we want to release aversion we merge the changes with the "head"?I think the multiple test sites for development are not needed since thedevelopers have their own copies locally, but I am not sure if this isthe "correct/comon" way of doing this.NitaiOn 28.5.2004 17:29 Uhr, "John Peacock"
wrote:> Nitai @ ComputerOil wrote:>=20>> Yes, but that does NOT solve the locking of files (so that not you=20>> and someone else can work on the same time on the same file) and=20>> versioning of your code.>=20> Databases should not be versioned resources, typically. If you have=20> multiple developers making multiple changes to database headers, you=20> only choice is branches and multiple test sites for development. If=20> you use exclusively relative path names for all files, you can do this>=20> http://developer1.test/site1> http://developer1.test/site2> http://developer1.test/site3> http://developer2.test/site1> http://developer2.test/site2> http://developer2.test/site3> ... etc.>=20> and then each developer gets his/her own branch both at the CVS level=20> and at the web server level.>=20> BTW, "Team Programming" is usually described as more than one person=20> developing the same files at the same time (often with the same=20> monitor and keyboard for Extreme Team Programming). I think you are=20> just talking about multiple developers interacting with the same=20> sites, so that is why I gave the advice above.>=20> You might also want to check out Subversion:>=20> http://subversion.tigris.org>=20> which is to a large extent the CVS - The Next Generation...>=20> John--Tools to energize your businessWeb Content Management & eBusiness SystemsComputerOil(r) AGDammstrasse 75400 Baden / SwitzerlandTelefon +41 (0)844 44 55 66info@computeroil.comhttp://computeroil.com-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail toWeb Archive of this list is at: http://webdna.smithmicro.com/-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
The WebDNA CMS is intended to be used by a team of developers withcheck-in, check-out, locking, workgroup access security model, etc.John is right in that any CMS/CVS isn't really intended for databasechanges, except in the sense that during a development cycle, you mayhave 'dev' versions of the databases where you are maintaining controlof the synchronization of code changes with DB schema changes. Theactual content of the DBs within a CMS/CVS is just test data at thatpoint. Once you move into a production deployment scenario, youcertainly wouldn't be deploying DB's from a CMS system ... Any DB in theCMS would be strictly as a test mule for validating code changes versusschema changes.With the WebDNA CMS, you can put in place some controls that will helpyou compartmentalize the development between the individual coders ...Create a separate workgroup for each developer, then set the workgroupprivileges such that each developer can only modify a subset of the codethey are directly responsible for. On any folders/files where thereneeds to be shared modifications you grant access across multipleworkgroups. For those areas that need careful integration, e.g., whencode and DB schema changes need to be migrated together, set up anapproval process with someone assigned the administrative responsibilityto review and control the rollout of those changes to the staging area.>From a logistical process with any CVS tool you choose ... On priorlarge development projects (20+ developers), I've always maintained thatif a developer checks something in, it had better be well unit testedand not break the overall project 'build' ... often due tointerdependencies with code written by other team members. This forcesdevelopers to think about any collaborative 'merges' they may need to dowith other team members prior to performing a check-in ... Or if acheck-in is going to fundamentally change some foundation object thatwill impact everyone else, this is broadcast in advance so everyoneknows to "get latest" and make their changes right after a new COMobject, DB schema, include file, etc., becomes part of the most recentversion in the CMS/CVS system. I've even pushed this to the point ofhaving automated nightly 'builds' of the latest version of everything inthe CMS/CVS ... If something broke the next morning due to someone'scheck-in, the responsible developer was tagged with fixing it ASAP.Even if a project was only 25% complete, that 25% worked every morningor someone got paged. From a QA perspective, we obviously didn't try todo full QA on every daily build ... We just maintained the teammentality that we always kept the most recent set of check-ins in astate where you 'could' perform QA at any given moment on the X% of theproject that was functionally complete.Phil B.-----Original Message-----From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com] On Behalf OfNitai @ ComputerOilSent: Friday, May 28, 2004 8:37 AMTo: WebDNA TalkSubject: Re: How do you TEAM Code?Yes, I mean many developers working with the "same" code.So if I understand you right, we create a branch for each developer.He/She works within that branch and then when we want to release aversion we merge the changes with the "head"?I think the multiple test sites for development are not needed since thedevelopers have their own copies locally, but I am not sure if this isthe "correct/comon" way of doing this.NitaiOn 28.5.2004 17:29 Uhr, "John Peacock" wrote:> Nitai @ ComputerOil wrote:>=20>> Yes, but that does NOT solve the locking of files (so that not you=20>> and someone else can work on the same time on the same file) and=20>> versioning of your code.>=20> Databases should not be versioned resources, typically. If you have=20> multiple developers making multiple changes to database headers, you=20> only choice is branches and multiple test sites for development. If=20> you use exclusively relative path names for all files, you can do this>=20> http://developer1.test/site1> http://developer1.test/site2> http://developer1.test/site3> http://developer2.test/site1> http://developer2.test/site2> http://developer2.test/site3> ... etc.>=20> and then each developer gets his/her own branch both at the CVS level=20> and at the web server level.>=20> BTW, "Team Programming" is usually described as more than one person=20> developing the same files at the same time (often with the same=20> monitor and keyboard for Extreme Team Programming). I think you are=20> just talking about multiple developers interacting with the same=20> sites, so that is why I gave the advice above.>=20> You might also want to check out Subversion:>=20> http://subversion.tigris.org>=20> which is to a large extent the CVS - The Next Generation...>=20> John--Tools to energize your businessWeb Content Management & eBusiness SystemsComputerOil(r) AGDammstrasse 75400 Baden / SwitzerlandTelefon +41 (0)844 44 55 66info@computeroil.comhttp://computeroil.com-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail toWeb Archive of this list is at: http://webdna.smithmicro.com/-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
"Phillip Bonesteele"
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
[WebDNA] Show next..... (2010)
splitting numbers in webDNA? (1997)
Re:Signal Raised (1997)
WCf2 and nested tags (1997)
Integrating Bar Codes with WebDNA (2006)
webcat NT (1998)
Spawning Holdup? (2000)
WebDNA 5.0 & WebMerchant (2003)
Need help with emailer- 2 issues (1997)
Webcatalog server support (1997)
WebCat2b15MacPlugin - showing [math] (1997)
WebCat2 several catalogs? (1997)
Emailer [cart] file names (1997)
Backwards list behavior ... (1997)
WebCat2.0 [format thousands .0f] no go (1997)
PCS Frames-Default page is solution! (1997)
Highlighting words found in a keyword search (2003)
Ampersand Character (&) (1997)
Database Structuring (again) (2003)
Garbage files created (2000)