Thanks, Aravid!

Those links help.

Any idea on how to pick a new strategy to keep the XML config from
getting so huge?  It takes 40 minutes to start up the go-server and we
think it is related to the giant XML config (or the in-memory data
structure that is its analog).  I find myself wondering if we should
have more than one server - or a cluster of servers - but the server
seems to be designed to be "one and only one".  Perhaps we could split
up development and production across two go-servers, but that only
gives us approximately a factor of 2.

Currently the only way we have to semi-automate refactoring is to cut
and paste the whole XML from the web UI into a text file, have a
script modify the XML and then paste the entire XML back into the web
UI (then check for errors after trying to save it).  Sometimes we step
on each others toes and end up rolling back someone's changes by
mistake using this method.

I think the new API offers better approaches than this (like the yaml
features you mentioned) but haven't had a chance to test them out
because we are running an old version.

Reading the docs and googling gets a hodgepodge of things from
different versions and it is hard to work out what might really work
for us.  I am hoping to learn from someone else's best practices by
reaching out to this list.

Brian Fennell

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAGJwi9hkokA%2Bdx9z-GHB8GWu-R9v2j4j3gSky-k_AjLt9%3DSDEQ%40mail.gmail.com.

Reply via email to