[RT] Site versioning, staging and deployment ( was Re: documentation/content made available to sitemap (Re: 'broken link' causes..))

[Nicola Ken Barozzi <ni...@apache.org>]

Robert Koberg wrote:
 > Hi,
 >
 > <rambling>
 > What about using subversion as the repos? You can set properties +
 > on a 'thing'.
 > Then some bright cocoon or forrest developer can come up with a way
 > to merge these properties into some kind of mapping XML to be used
 > in the transformation.
 >
 > In fact the subversion repos could serve the appropriate version
 >  of the site (to all stagiing environments).
 >
 > You can also get conflicts back as well-formed XML so sometimes,
 > you might be able to fix a merge or provide a gui for
 > non-technical users to fix it.
 > </rambling>

I think that it's in the best interest of the users to have an all-java
solution in Forrest, and be able to use the filesystem as now, so I 
won't want to tie Forrest to subversion.
Besides, Jakarta Slide is a CMS in Java that can use WebDav and 
eventually use Subversion as a backend too.

That said, the fact you brought up subversion gives me the opportunity
to start a discussion about how to manage real-life Forrest sites.

With Mr. Rodent, we have talked about what his expectations were with 
Forrest usage, and I summed them up in my head with all the other stuff 
heard on the dozen lists I have polled.

These are the requirements I think I have understood:

   1) the system must be updateable to the live site manually
   2) an automatic system may be used to generate a dev
      version of the site
   4) the source must be committed to a VCS
   5) the results of the docs build must be committed to a VCS,
      to keep history of the generated version
   6) an automatic system may publish the site from VCS with a
      sensible time delay, possibly random to minimize the
      possibility of bad content being pushed intentionally
      or erroneously on the site
   7) the automatic publishing system must run from the
      destination site for security reasons: it will
      _pull_ content from the generation site.
   8) The document build system should not reside in VCS;
      it's recommended that in VCS there is an automated
      system to aid in the installation of the build system.


I don't agree with all, but nevertheless we must address them, and come 
to a solution to all the _needs_ that bring users to define these 
requirements.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
              - verba volant, scripta manent -
     (discussions get forgotten, just code remains)
---------------------------------------------------------------------



-- 
Nicola Ken Barozzi                   nicolaken@apache.org
              - verba volant, scripta manent -
     (discussions get forgotten, just code remains)
---------------------------------------------------------------------

RE: [RT] Site versioning, staging and deployment ( was Re: documentation/content made available to sitemap (Re: 'broken link' causes..))

[Robert Koberg <ro...@koberg.com>]

Hi,

> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Tuesday, November 05, 2002 2:13 AM
>
> These are the requirements I think I have understood:
>
>    1) the system must be updateable to the live site manually
>    2) an automatic system may be used to generate a dev
>       version of the site
>    4) the source must be committed to a VCS
>    5) the results of the docs build must be committed to a VCS,
>       to keep history of the generated version
>    6) an automatic system may publish the site from VCS with a
>       sensible time delay, possibly random to minimize the
>       possibility of bad content being pushed intentionally
>       or erroneously on the site

content, pages and folders could have some status property to indicate their
current state (editorial, archive, static, etc). This could or could not be
observed by the build system to only build what is appropriate for the stage of
the project.

>    7) the automatic publishing system must run from the
>       destination site for security reasons: it will
>       _pull_ content from the generation site.

I would think that you *should* copy to the live site. The site should be
developed, tested, certified, then copied to 'live.'

When it is certified, it is like a gold master from CDROM days

Staging is nothing new - I did not come up this methodology - it is tried and
tested. I think it also shows your client/whoever-you-serve that you are taking
a professional approach to the project's development. It simplifies things a
great deal. You always are sure that only a certified site will be pushed live.

best,
-Rob


>    8) The document build system should not reside in VCS;
>       it's recommended that in VCS there is an automated
>       system to aid in the installation of the build system.
>
>
> I don't agree with all, but nevertheless we must address them, and come
> to a solution to all the _needs_ that bring users to define these
> requirements.
>
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>               - verba volant, scripta manent -
>      (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>