Difference between revisions of "U.s.oo.o/Planning/Site/CM"
DrewJensen (Talk | contribs) (→Configuration Management) |
(→Configuration Management) |
||
(6 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
==Configuration Management== | ==Configuration Management== | ||
− | Use of vc tool on the new server or use of existing vc repository on an existing server? | + | Use of vc tool on the new server or use of existing vc repository on an existing server?<br> |
+ | Development environment: | ||
+ | #Where ( for example, should we keep a separate directory structure, database on the server for one dev/testing implementation. | ||
+ | #Steps to move from the dev / test implementation to the live implementation | ||
+ | *What should be checked in to vc system | ||
+ | *Any backup steps that should be taken first | ||
+ | *Notifications to users | ||
− | [[User:DrewJensen|Drew]] 00:14, 10 September 2007 (CEST)I would vote | + | What about moving things from the a local PC to the site testing implementation? |
+ | |||
+ | There is also a cross over responsibility here within the disaster recovery plan - not sure which needs the section. I think there. | ||
+ | |||
+ | [[User:DrewJensen|Drew]] 00:14, 10 September 2007 (CEST)I would vote for doing our own on the new server. | ||
+ | |||
+ | [[User:TerryE|TerryE]] 02:38, 15 September 2007 (CEST) -- Configuration management of a COTS based configuration is slightly complicated in that the live build is a blend of a package at a given version which is a single CI; its deployment script which is another CI and the individual patches and their deployment scripts (which in the case of a patch, the easiest way to implement this is as a bundled script so there is only the patch which is a say a tarball with a mandatory install.sh element), so the each individual patch is a CI. Even so we still get into impact analysis PCMs and regression testing if we need up the base package version. We should also use a basic ITIL compliant administration model here. | ||
+ | |||
+ | |||
+ | ''Author: [mailto:atjensen@openoffice.org?subject:CM wiki page] <br> created [[User:DrewJensen|Drew]] 9 September 2007 (CEST)'<br> | ||
+ | ''Please do not change the logical content of this site without | ||
+ | acknowledge of the author or the [http://wiki.services.openoffice.org/wiki/User:DrewJensen/User_services_Contact_list UCV Contact list].'' | ||
+ | |||
+ | [[Category:UCV]] |
Latest revision as of 00:38, 15 September 2007
Configuration Management
Use of vc tool on the new server or use of existing vc repository on an existing server?
Development environment:
- Where ( for example, should we keep a separate directory structure, database on the server for one dev/testing implementation.
- Steps to move from the dev / test implementation to the live implementation
- What should be checked in to vc system
- Any backup steps that should be taken first
- Notifications to users
What about moving things from the a local PC to the site testing implementation?
There is also a cross over responsibility here within the disaster recovery plan - not sure which needs the section. I think there.
Drew 00:14, 10 September 2007 (CEST)I would vote for doing our own on the new server.
TerryE 02:38, 15 September 2007 (CEST) -- Configuration management of a COTS based configuration is slightly complicated in that the live build is a blend of a package at a given version which is a single CI; its deployment script which is another CI and the individual patches and their deployment scripts (which in the case of a patch, the easiest way to implement this is as a bundled script so there is only the patch which is a say a tarball with a mandatory install.sh element), so the each individual patch is a CI. Even so we still get into impact analysis PCMs and regression testing if we need up the base package version. We should also use a basic ITIL compliant administration model here.
Author: wiki page
created Drew 9 September 2007 (CEST)'
Please do not change the logical content of this site without
acknowledge of the author or the UCV Contact list.