didactic_cudgel: (Default)
didactic_cudgel ([personal profile] didactic_cudgel) wrote in [site community profile] dw_dev2011-05-17 02:08 pm
  • Add Memory
  • Share This Entry
Entry tags:

Keeping production current.

I run a production DW-powered site and I want to keep it up to date with the latest code fixes and features.

In asking #dreamwidth-dev about following this procedure: http://wiki.dwscoalition.org/notes/Dev_Maintenance firefoxfey recommended that I find out what the latest post-release final tag is an update only to that tag to avoid getting untested dev features, but didn't know the procedure. I was advised to ask here and so I am :)

If I want to keep my code current, but reduce the chance of pulling down untested code, how do I find and limit code to the post-release final tag?

Also, Fey suggested making sure that I'm aware of any database changes. Are those announced separate from code pushes?
Flat | Top-Level Comments Only
kareila: (Default)

[personal profile] kareila 2011-05-18 02:34 am (UTC)(link)
I think you would have to manually cd into cvs/dw-free, do "hg tags" to see what the most recent tag is (currently 1.0.0) and then "hg update -r [tagname]" to get that revision. Then use cvsreport -sync as normal to sync the files from the cvs directory to the working directory. We should probably update the cvsreport script to make this easier.

As for database changes, we've only had one of those so far and we've announced it in this community using the "dversions" tag.
didactic_cudgel: (Default)

[personal profile] didactic_cudgel 2011-05-18 06:01 pm (UTC)(link)
Thank you!
When I run that, I get this:
dwcode@bigender:~/cvs/dw-free$ hg tags
tip 3515:6b78ac69e1ce
0.21.1 3509:84c93c064842
0.21.0 3507:b4ded6f957d3
0.20.2 3452:1ed6242bf43f
0.20.1 3448:2f61583503c7
0.20.0 3443:0ee92a93a23f


I don't see 1.0.0. I'm confused, I'm sorry.
Edited 2011-05-18 18:03 (UTC)
kareila: (Default)

[personal profile] kareila 2011-05-18 07:32 pm (UTC)(link)
Ah, you have to do the cvsreport -update first, and then you should have 1.0.0. Sorry!
exor674: Computer Science is my girlfriend (Default)

[personal profile] exor674 2011-05-19 08:26 am (UTC)(link)
Well, there are occasional simple database changes that can be done with db-update...
For those, I'd just run cvsreport itself ( not with -sync ) and if update-db-general.pl, then you've got a simple changes.

db-update should be ran every update, anyway.

Any more complicated changes will be as [personal profile] kareila said.

It may be safest to wait a week or two after the code push before updating to the latest tag ( and stay one push behind until then ), so we can catch any lingering issues ( we are already on 1.0.1 due to some issues from the push )

For a production site, to minimize surprises:


  • You are going to want to have *all* of your configuration files copied into cvs/<dir I had you create>/etc, and compare the diffs between versions to see if there are any important changes.

  • You should probably run cvsreport first w/o args before -sync, to make sure you know what is changing.



didactic_cudgel: (Default)

Full Update/Upgrade/Procedure

[personal profile] didactic_cudgel 2011-05-19 01:28 pm (UTC)(link)
OK ... soo ... just to make sure I understand. The procedure should be:

  1. See Code Push in [site community profile] dw_maintenance.

  2. Run cvsreport -update

  3. Run cvs/dw-free/hg tags - note Tag info

  4. Wait one week or so.

  5. Run cvs/dw-free/hg tags -
    • a. If highest (non-tip?) tag is different, wait one week more and repeat step.

    • b. If highest tag matches, proceed.

  6. Copy all config files to cvs/< my journal local >/etc/
    • a. Do this for any file I've modified in the code, like schemes, etc? - copied into their own cvs/< my journal local >/< original path >?

    • b. Do schemes follow the same "override with -local" effect as the config files? If I've modified vertical-gradation heavily, will it be overwritten with a code-push? Will gradation-vertical-local override gradation-vertical?

  7. Run "hg update -r [tagname]"

  8. Run diff on the files in cvs/< my journal local >/etc/config* to make sure none of my changes will be overwritten - any overwritten changes should be moved to a -local.pl file.

  9. sudo /etc/init.d/apache2 stop

  10. cd $LJHOME

  11. run cvsreport.pl without arguments to get a preview of changes being implemented

  12. bin/cvsreport.pl -sync -cvsonly

  13. bin/cvsreport.pl -sync -cvsonly

  14. LJHOME/bin/upgrading/update-db.pl -r -p --innodb

  15. $LJHOME/bin/upgrading/update-db.pl -r --cluster=all --innodb

  16. $LJHOME/bin/upgrading/texttool.pl load

  17. start apache


Does that look right? I could also, I assume, create the update scripts in the Dev_Maintenance wiki (where a lot of this info came from) and replace the relevant parts in my list here.
Edited 2011-05-19 13:32 (UTC)
exor674: Computer Science is my girlfriend (Default)

Re: Full Update/Upgrade/Procedure

[personal profile] exor674 2011-05-19 02:35 pm (UTC)(link)
You really should be fine waiting a week, just monitor the dw-maint post to see if there are any lingering issues and just make sure no new tags show up with the minor ( that is 1.0.x -- the x changing ) different.

6. You should not be overriding any files, really -- because you will miss out on any changes, and they could cause incompatibilities -- besides the config files.

What are you overriding? -- anything that DW has needed to should have a local component or a hook.

6b. See:

http://hg.dwscoalition.org/dw-nonfree/file/6883b468b6b7/schemes/_dreamwidth.tt
http://hg.dwscoalition.org/dw-nonfree/file/6883b468b6b7/schemes/gradation-vertical-local.tt
http://hg.dwscoalition.org/dw-nonfree/file/6883b468b6b7/cgi-bin/DW/Hooks/SiteScheme.pm

And then use grad-vertical-local in all your config places.

But any file you create yourself should be in your cvs/<blah> directory.

7. You should also do that to the closest tag before [tagname] ( or past, if there's a different minor ) in:

dw-free
bml
js
perlbal
s2

8. No, compare the config files with 'hg diff -r <last tag> etc/config.pl' ( and the same with the two templates in doc ) and merge in any relevant looking changes ( new options, etc... )

11. Yep, and you can 'cvsreport.pl --diff filename' if you want to see what changed.
didactic_cudgel: (Default)

Re: Full Update/Upgrade/Procedure

[personal profile] didactic_cudgel 2011-05-19 04:01 pm (UTC)(link)
6a. I'm not positive that I did, very much, except for the vertical-gradation scheme because I'm a bit bumbly and didn't know any better - despite the warnings in the scratch installation code, that is. I didn't understand the relationship between x.file and x-local.file before. Yay! Bring out the sub, I'm goin' code-divin'!

6b. Thank you :)

7. Are you saying to run hg update from each folder?

8. Thank you

11. Neat! :)

Thank you all. I have a history of jumping feet first into things I don't understand even a little. Same thing happened with phpBB3. I knew this would be complex, but, as always, I underestimated the complexity and overestimated my ability. You've helped make this so much more painless. Not only I appreciate it, but my users do too. :)
exor674: Computer Science is my girlfriend (Default)

[personal profile] exor674 2011-05-19 04:10 pm (UTC)(link)
There's no explicit handling of -local, you could name your scheme didactic-cudgels-awesome-grad-horizontal-variant-of-science or whatever -- which is why you have to name the local one when you want to use it ( see http://www.dreamwidth.org/?usescheme=celerity v.s. http://www.dreamwidth.org/?usescheme=celerity-local )

Certain things look for a local file, those being, the database updater for the s2 layer list and update-db-general, as well as a few other things.


7. Yeah, Tankfully most others are very rarely updated, but you don't want to suck something in accidentally.
Flat | Top-Level Comments Only