Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of donal.lafferty@citrix.com
 designates 185.25.65.24 as permitted sender)
From: Donal Lafferty <donal.lafferty@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: RE: [PROPOSAL] Using continuous integration to maintain our code
 quality...
Thread-Topic: [PROPOSAL] Using continuous integration to maintain our code
 quality...
Thread-Index: Ac9phfCcUZHuC6ncQyC8gXLKm7nsFQATcbiw
Date: Wed, 7 May 2014 09:20:22 +0000
Message-ID: 
 <9ADDE3F979256644BED8F0D244BE51F0040CF44A@AMSPEX01CL02.citrite.net>
References: <20CF38CB4385CE4D9D1558D52A0FC05870768C@SJCPEX01CL03.citrite.net>
In-Reply-To: <20CF38CB4385CE4D9D1558D52A0FC05870768C@SJCPEX01CL03.citrite.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

How about some gamification? :)

Continuous integration allows devs to gage whether they're coding too fast =
for quality conditions.  Can we introduce a penalty points system to get th=
em to slow down?

E.g. 3 pts / offence, mandatory 3rd party code reviewers after 15 over two =
releases cycles?


> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: 07 May 2014 01:04
> To: dev@cloudstack.apache.org
> Subject: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>=20
> Hi All,
>=20
> This is something I brought up a long time ago but really didn't have the
> resources to get it all up and running until now.  Throughout the past ye=
ar,
> Edison, Prasanna, Amogh, Bharat, Koushik, Talluri, and others have been
> chipping away at it.  At this point, we finally pull together a continuou=
s
> integration setup that we can use to make sure that CloudStack master and
> the currently release branch are always stable.  This is getting pretty c=
lose to
> be completed and we like to share it with the community in hopes that we
> can reduce/eliminate that problems we've seen with our recent releases.
> Currently, the physical hardware are hosted by Citrix but we'll be more t=
han
> willing to donate the work to infra when that's all settled.
>=20
> This does require effort from the community to make a change in their
> development process.  These steps are detailed at [1].  I like to get fee=
dback
> on what everyone think about this.
>=20
> What have we done:
>   - We replaced a large selection of the BVT tests to run with the simula=
tor
> instead of actual hardware.  This shortens the duration of each BVT run.
> Today, a BVT that runs tests for XenServer and KVM completes in 30-40
> minutes.
>   - We will run the new BVT on master and the current release branch on a
> continuous basis.
>   - Developers can use Jenkins to ask BVT to be run on their branch so th=
ey
> can know it won't break the continuous integration before they merge to
> master and the current release branch.
>=20
> Please have a read and let me know what you think.
>=20
> --Alex
>=20
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+P
> rocess