Re: best production practice?
Hello, Thanks for the answers. I also agree with Jim, but it might be hard to convince content people that they have to go throught a staging first, for simple stuff. I will definitly do whatever i can, tho :). Todd, what you're saying refers actually to what i'm asking: the production code is a checked out copy? (with the cvs folders, etc...). We already have a tag/branch procedure. The problem is, as now, we have a cvs export copy on production (and no cvs client on production either...). I'm wondering if it would be better to install a cvs client, and have the code being a cvs checkout copy. That way, we could do like you're proposing, with cvs diff. I'm actually just wondering if doing it that way has some drawbacks, vs doing a cvs export/tar-gzip/scp procedure. Regards, Bobby From: Todd Denniston [EMAIL PROTECTED] To: Jim.Hyslop [EMAIL PROTECTED] CC: 'bobby temper' [EMAIL PROTECTED], info-cvs@gnu.org Subject: Re: best production practice? Date: Wed, 09 Feb 2005 17:18:36 -0500 Jim.Hyslop wrote: bobby temper wrote: What i meant is that, we have the code running on a production machine. Now and then, that code gets changed, and sometimes, it's content gets out of sync with whats on production (ie. for example. someone edit directly on production, for a hotfix (i know this is bad, but fast for changing a simple text, link, etc...) and forget to do the changes in cvs. This practise *MUST* stop. Do whatever it takes to make it stop, otherwise one day you *will* get burned, and badly. Changing a simple text is no excuse. Problem solved. I agree with Jim that you must stop the practice, as it *will* get burned, however Jim he still needs a method to DETECT violation of the integrity of the production set, for as long as he is still working with his bosses to get the policy fixed. for detection, the following might do it. if you use tags to checkout for a release, try `cd head/of/project/; cvs diff -rTagShownInThisSet`, if you get anything, a violation has occurred, attempt to find the violator and use a LART as necessary. without tags just using `cvs diff ` might get you started, if you get anything, a violation has occurred, attempt to find the violator and use a LART as necessary. Also without tags, it is time to talk to the boss and get the procedure changed at least to indicate releases shall be made only from tags. All Production releases should be if possible made by using your build system, or a release build system, to do a checkout, tag if the checkout was not of a tag, build package, in this way you can be sure to be able to recreate releases. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer. _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: best production practice?
bobby temper wrote: I also agree with Jim, but it might be hard to convince content people that they have to go throught a staging first, for simple stuff. In my experience, it's usually the simple stuff that causes the most headaches ;=) I'm wondering if it would be better to install a cvs client, and have the code being a cvs checkout copy. That way, we could do like you're proposing, with cvs diff. I'm actually just wondering if doing it that way has some drawbacks, vs doing a cvs export/tar-gzip/scp procedure. The drawback would be having to administer another installation of a cvs client. Not much overhead, I think. One advantage - you can check in changes directly from any production hot-fixes. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
[slightly OT] Re: best production practice?
bobby temper wrote: Hello, Thanks for the answers. I also agree with Jim, but it might be hard to convince content people that they have to go throught a staging first, for simple stuff. I will definitly do whatever i can, tho :). Todd, what you're saying refers actually to what i'm asking: the production code is a checked out copy? (with the cvs folders, etc...). We already have a tag/branch procedure. The problem is, as now, we have a cvs export copy on production (and no cvs client on production either...). I'm wondering if it would be better to install a cvs client, and have the code being a cvs checkout copy. That way, we could do like you're proposing, with cvs diff. I'm actually just wondering if doing it that way has some drawbacks, vs doing a cvs export/tar-gzip/scp procedure. OUCH. OK, I am sometimes considered an SOB by those that work with me when it comes to releases, but it sounds like it is time for 1) the production machine to have the number of user names reduced to root+otherinstalleddefaultusers projectadmin or 2) the production area locked down so only root project admin can make modifications. If I was the person who had to answer what is in the production machine today?, I would make three documents document 1) I, [my name], have permission to [insert lock down method] the production [machine|area], and anyone who subverts that gets [insert appropriate punishment]. This will be implementing an industry best practice [site sources (besides/in addition to Jim me)][1] boss_signature_hereDate. document 2) I, [my name], am not responsible for the content of the production machine even though it has been suggested to customers we have someone in that job. boss_signature_hereDate. document 3) I, [my name], have informed [boss's name] that the production [machine|area], is out of control, and anyone with [insert level of access] can modify it at will and the changes will not be recorded in version control, so we can not track who or when a change was made. I, [my name], have informed [boss's name] of the following method for correcting the situation and been denied. [insert method(s) here] boss_signature_hereDate. I would then take them to my boss, and indicate s/he should pick one and sign it. BTW I am camping as physically close to my boss's person as is possible during working hours until one is signed. :) 1 gets you the ability to fix the problem. 2 indicates it should not be your butt that is the one to kick if there is a problem with what is on the production machine/area. 3 indicates the boss's butt is the one to kick _if/WHEN_ there is a problem with what is on the production machine/area. If the boss refuses to sign any of them... 1) email the concerns and fixes to the boss, and print a copy. 2) keep a note book recording the documents, the email when they were presented. 3) consider if it is worth going to the boss's boss with the notebook. Sometimes you just have to drop back to these kind of strong arm tactics to get what is needed, and keep your own head. if the boss picks #1 (this is what you hope for), you can implement the corrective change ... tell the complaining people the boss indicated it should be done, and (to relieve some of the stress you just applied to his/her arm) tell the boss to tell them we are implementing industry best practices...(pause to see if they complain more, if so finish with) you will work with it. If you do not feel it is best practice, document why, and site your sources. before they show up in the bosses office. Regards, Bobby SNIP [1] you could start by searching the mailing list for other people dealing with release management http://www.cmcrossroads.com/bradapp/acme/ http://www.cmcrossroads.com/bradapp/acme/#BuildRepro http://www.cmcrossroads.com/bradapp/acme/repro/SoftwareReconstruction.html http://lists.gnu.org/pipermail/info-cvs http://www.google.com/search?hl=enq=release+managmentbtnG=Google+Search http://www.google.com/search?hl=enlr=q=%22release+managment%22+CVSbtnG=Search http://www.google.com/search?hl=enlr=q=%22release+management%22btnG=Search http://www.google.com/search?hl=enlr=q=%22release+management%22+CVSbtnG=Search http://www.google.com/search?hl=enlr=q=%22release+management%22+%22best+practices%22btnG=Search http://www.google.com/search?hl=enlr=q=%22release+management%22+%22best+practices%22+cvs+-pvcsbtnG=Search http://www.w3.org/OOP/9606_Workshop/submissions/31-W3COMG.html http://www.wipro.com/prodesign/focusareas/complatforms/complatpcasestudy8.htm you get the picture right? -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
[slightly OT] Re: best production practice?
Hi, A pragmatic way to do it is to do put updates on the server using: cvs co -rRELEASE_20 proj Then, ... To make a quick fix, get the latest source code on your dev environment, bump up the version number in your dev environment (even on your local machine running apache/iis/whatever). Tag it using cvs rtag, then do an rdiff to examine changes. Go through any change procedure (which for a single textbox caption should not be too onerous). Then, update the production server using: cvs up -rRELEASE_21 It shouldn't be too hard. The key is to make sure there is an easy place to edit the site in a dev environment. So, for a start -- don't version control the database config files or you'll have pain where prod and dev are fighting over which database connection to use. People can then go up and fiddle with the labels in 5 seconds -- but it doesn't show up to customers until you hit the big button. If you make it easy for people they shouldn't complain. You definitely want a release controlled environment, but at the same time, a system which involves lots of work just to change a single line of code is problematic and needs to be automated at some level (the grunt work, not the decisions, that is). Another thing -- don't be shy about creating versions: there's no problem with making several hundred versions which include nothing more than minor fixes to things here and there. Given that, no prob in making a script which fetches all tags, gets the highest release number, tags the next increment, and spits out a diff and patchset onto the desktop. People will love you for it. :) My 5 new/250 old francs, Cheers, Matthew Herrmann --- Far Edge Pty Ltd http://www.faredge.com.au/ Level 6, 35 Chandos Street St Leonards 2065 Ph: +612 8425 1400 -Original Message- bobby temper wrote: Hello, Thanks for the answers. I also agree with Jim, but it might be hard to convince content people that they have to go throught a staging first, for simple stuff. I will definitly do whatever i can, tho :). Todd, what you're saying refers actually to what i'm asking: the production code is a checked out copy? (with the cvs folders, etc...). We already have a tag/branch procedure. The problem is, as now, we have a cvs export copy on production (and no cvs client on production either...). I'm wondering if it would be better to install a cvs client, and have the code being a cvs checkout copy. That way, we could do like you're proposing, with cvs diff. I'm actually just wondering if doing it that way has some drawbacks, vs doing a cvs export/tar-gzip/scp procedure. OUCH. OK, I am sometimes considered an SOB by those that work with me when it comes to releases, but it sounds like it is time for 1) the production machine to have the number of user names reduced to root+otherinstalleddefaultusers projectadmin or 2) the production area locked down so only root project admin can make modifications. If I was the person who had to answer what is in the production machine today?, I would make three documents document 1) I, [my name], have permission to [insert lock down method] the production [machine|area], and anyone who subverts that gets [insert appropriate punishment]. This will be implementing an industry best practice [site sources (besides/in addition to Jim me)][1] boss_signature_hereDate. document 2) I, [my name], am not responsible for the content of the production machine even though it has been suggested to customers we have someone in that job. boss_signature_hereDate. document 3) I, [my name], have informed [boss's name] that the production [machine|area], is out of control, and anyone with [insert level of access] can modify it at will and the changes will not be recorded in version control, so we can not track who or when a change was made. I, [my name], have informed [boss's name] of the following method for correcting the situation and been denied. [insert method(s) here] boss_signature_hereDate. I would then take them to my boss, and indicate s/he should pick one and sign it. BTW I am camping as physically close to my boss's person as is possible during working hours until one is signed. :) 1 gets you the ability to fix the problem. 2 indicates it should not be your butt that is the one to kick if there is a problem with what is on the production machine/area. 3 indicates the boss's butt is the one to kick _if/WHEN_ there is a problem with what is on the production machine/area. If the boss refuses to sign any of them... 1) email the concerns and fixes to the boss, and print a copy. 2) keep a note book recording the documents, the email when they were presented. 3) consider if it is worth going to the boss's boss with the notebook. Sometimes you just have to drop back to these kind of strong arm tactics to get what is needed, and keep your own head. if the boss picks #1 (this is what you hope for), you can implement
Re: best production practice?
Hello bobby, I am not sure what you mean, but I have written a litte script which activates on tag commands with certain names, as I do not want every checkin from everybody to go into the production environment. Then it does a cvs export, builds the sources and - if no error - emails the source and installs the binaries. Is that like something you are looking for? Bye Alex Am 09.02.2005 um 04:17 schrieb Rachel Burns: bobby temper wrote: Hello CVS users, The company i work for is having difficulties keeping production and the repository in sync'. Not sure what you mean by production and repository in sync ? Did you mean to say you want to have two repositories that need to be kept in sync ? If yes you may want to look at http://www.wandisco.com/cvs for keeping multiple replicas in sync. I would like to know, what is the best practice to achieve this? I'm thinking of having a cvs client on production, and having the production code being a checked out copy, with a cron job doing a cvs -n update, and emailing the results. But I am not sure thats the best way, as Looks like you want to determine what changed against a poduction tag/branch ? If yes you might want to create a tag and diff against that. other problems might occur with this solution. I would like to know if any of you have a better solution, or see the pitfalls in such solution. Thanks for your help, Best regards, Bobby _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: best production practice?
Hello, What i meant is that, we have the code running on a production machine. Now and then, that code gets changed, and sometimes, it's content gets out of sync with whats on production (ie. for example. someone edit directly on production, for a hotfix (i know this is bad, but fast for changing a simple text, link, etc...) and forget to do the changes in cvs. I would like a way to know when the code on production isn't the same as the one in the source control (not to update production, but to update the repository). So far, the best way i thought of doing this was to have a cvs client on the production servers, and periodically (cron job) do a cvs -n update, logging the results. Now that means all our sites will have CVS folders, large updates will go throught cvs update, etc. I would like to know if that's the best method of doing what i would like. Best regards, Bobby From: Rachel Burns [EMAIL PROTECTED] To: bobby temper [EMAIL PROTECTED] CC: info-cvs@gnu.org Subject: Re: best production practice? Date: Tue, 08 Feb 2005 19:17:36 -0800 bobby temper wrote: Hello CVS users, The company i work for is having difficulties keeping production and the repository in sync'. Not sure what you mean by production and repository in sync ? Did you mean to say you want to have two repositories that need to be kept in sync ? If yes you may want to look at http://www.wandisco.com/cvs for keeping multiple replicas in sync. I would like to know, what is the best practice to achieve this? I'm thinking of having a cvs client on production, and having the production code being a checked out copy, with a cron job doing a cvs -n update, and emailing the results. But I am not sure thats the best way, as Looks like you want to determine what changed against a poduction tag/branch ? If yes you might want to create a tag and diff against that. other problems might occur with this solution. I would like to know if any of you have a better solution, or see the pitfalls in such solution. Thanks for your help, Best regards, Bobby _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: best production practice?
On Wed, Feb 09, 2005 at 03:52:29PM +, bobby temper wrote: Hello, What i meant is that, we have the code running on a production machine. Now and then, that code gets changed, and sometimes, it's content gets out of sync with whats on production (ie. for example. someone edit directly on production, for a hotfix (i know this is bad, but fast for changing a simple text, link, etc...) and forget to do the changes in cvs. I would cvs checkout to a staging server and then make a package to install on the production server, such as rpm or deb. That allows you to give your production releases version numbers. I've also used tagged cvs check outs to mark releases. And also just simply cvs for simple sites. But being structured with packaged releases is nice. I would like a way to know when the code on production isn't the same as the one in the source control (not to update production, but to update the repository). So far, the best way i thought of doing this was to have a cvs client on the production servers, and periodically (cron job) do a cvs -n update, logging the results. That's to check for changes on the production server? -- Bill Moseley [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: best production practice?
bobby temper wrote: What i meant is that, we have the code running on a production machine. Now and then, that code gets changed, and sometimes, it's content gets out of sync with whats on production (ie. for example. someone edit directly on production, for a hotfix (i know this is bad, but fast for changing a simple text, link, etc...) and forget to do the changes in cvs. This practise *MUST* stop. Do whatever it takes to make it stop, otherwise one day you *will* get burned, and badly. Changing a simple text is no excuse. Problem solved. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: best production practice?
Jim.Hyslop wrote: bobby temper wrote: What i meant is that, we have the code running on a production machine. Now and then, that code gets changed, and sometimes, it's content gets out of sync with whats on production (ie. for example. someone edit directly on production, for a hotfix (i know this is bad, but fast for changing a simple text, link, etc...) and forget to do the changes in cvs. This practise *MUST* stop. Do whatever it takes to make it stop, otherwise one day you *will* get burned, and badly. Changing a simple text is no excuse. Problem solved. I agree with Jim that you must stop the practice, as it *will* get burned, however Jim he still needs a method to DETECT violation of the integrity of the production set, for as long as he is still working with his bosses to get the policy fixed. for detection, the following might do it. if you use tags to checkout for a release, try `cd head/of/project/; cvs diff -rTagShownInThisSet`, if you get anything, a violation has occurred, attempt to find the violator and use a LART as necessary. without tags just using `cvs diff ` might get you started, if you get anything, a violation has occurred, attempt to find the violator and use a LART as necessary. Also without tags, it is time to talk to the boss and get the procedure changed at least to indicate releases shall be made only from tags. All Production releases should be if possible made by using your build system, or a release build system, to do a checkout, tag if the checkout was not of a tag, build package, in this way you can be sure to be able to recreate releases. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the WarfighterThe opinions expressed here are not sanctioned by and do not necessarily represent those of my employer. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
best production practice?
Hello CVS users, The company i work for is having difficulties keeping production and the repository in sync'. I would like to know, what is the best practice to achieve this? I'm thinking of having a cvs client on production, and having the production code being a checked out copy, with a cron job doing a cvs -n update, and emailing the results. But I am not sure thats the best way, as other problems might occur with this solution. I would like to know if any of you have a better solution, or see the pitfalls in such solution. Thanks for your help, Best regards, Bobby _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
