cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [PROPOSAL] Using continuous integration to maintain our code quality...
Date Thu, 15 May 2014 21:01:16 GMT
> 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


Mime
View raw message