We have put up a wiki(initial cut\draft), will add more information once time permits
https://cwiki.apache.org/confluence/display/CLOUDSTACK/New+Infrastructure,CI,Simulator,Automation+Changes Thanks! Santhosh ________________________________________ From: Alex Huang [alex.hu...@citrix.com] Sent: Thursday, May 15, 2014 5:01 PM To: dev@cloudstack.apache.org Subject: RE: [PROPOSAL] Using continuous integration to maintain our code quality... > On Wed, May 14, 2014 at 06:21:34PM +0000, Alex Huang wrote: > > I think infrastructure code should just be checked in with the source > > code. To separate it means you have to deal with version > > match/mismatch between infrastructure and source code. > > Sorry - that doesn't sound right. Usually infrastructure code has little to do > with the source code other than deploying the packages built from said > source. Could you please clarify the bits that go into this infra code and > why it > should be affected by versions? [*] If it's config management recipes those > are usually maintained separate from source of your web-tier. Infra code is > maintained and changed usually more rapidly. I don't get why jenkins > settings and config management should exist within our catch-all tools dir. > We're going to bloat it up unnecessarily and realise later it should have been > a separate repo to begin with - for eg. cloudmonkey or marvin. Let me put out what I consider as a requirement. The requirement is any changes in framework, infrastructure, configuration, recipes, scripts, source code, marvin, etc, cannot affect CI that has been established on released branches. You have to look at CI like build for source code. When a release is done, you take a label or a branch and you're fairly certain it will build again. CI has to be the same, I might have shut it down for a release for a while but if I have to dust it off, I have to be fairly certain it runs again without a lot of debugging. Now if there are well established components, like Jenkins or Mysql that we can just specify the version # like we do with maven in build, then it's fine not to include it in the source tree. But if the components used by CI is not a well versioned independent entity, then we should include it in the source tree and branch it with the release or risk CI breaking for that release. For things like this, I rather not guess too optimistically about the chances. We have to treat CI running on released branches to be like production systems. The best thing to do for a production system that works is to don't let anyone touch any part of it, as any ops guy will tell you. > > [*] the wiki did not have enough information about the infra-code It's not intended to. The wiki is meant to provide what developers and testers should do. It's not to explain the infrastructure code. I'm sure Santhosh and others will document what they've done and how others can take advantage. --Alex
