You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2015/06/29 23:21:46 UTC

Continuous Integration Redux

Hey all,

last week I did a bit of outreach on Twitter, trying to grow our CI team. “What CI team?” you ask. — Exactly.

CouchDB needs world-class continuous integration in order to guarantee that we deliver quality software across many platforms and configuration without wasting too much time.

In the past, I’ve handled the CI setup (http://ci.couchdb.org:8888 / rough docs at: http://wiki.apache.org/couchdb/CI where you see that we are a little out of date ;) on a Mac Mini in my home. It was meant as a temporary measure until a larger team could take over. This never happened and we are trying to revive the effort now for the upcoming 2.0 release.

Before you ask: we are already using Travis CI, and it is really nice to do baseline checks for ongoing development and Pull Requests, but it is inadequate to satisfy all our testing needs. In particular testing on multiple operating systems, different operating system versions, dependency versions and configurations (and Windows!) — I’m very good personal friends with the Travis team, and they want to work towards supporting these things, but it’s nowhere near on their roadmap, and we need better CI now.


## There are a bunch of things to do

Before I go into details, I’d like to point out that the most important thing we need here is someone, or better a group of people that are *interested in assuming ownership of the CouchDB Continuous Integration operations*. 

You’ll be part of a uniquely friendly community and would work on something, while sometimes thankless, that would be of incredible benefit to the project. And we are here to hold your hands getting started. :)

Also, nothing here requires any specific Erlang knowledge. Any test suites are up to the Erlang devs in the community and other than that, Erlang is just another Unix/Windows binary, nothing special required, *and* you have a bunch of experts eager to help you at your disposal :)

And one final prelude item: While these things might seem overly specific, it doesn’t really matter how you arrive at what we need. One of the appeals of Open Source is to do your own thing and see that it helps, so if you have a completely different vision for CI that would give us the same or even better benefits, by all means, it’s your show :)

With all that out of the way, there are multiple areas that need tackling:

- Coordination with the ASF Infra/CI team for the existing Jenkins setup and build-machine configuration (we can continue to use ci.couchdb.org:8888 for a while but eventually, this should live on ci.apache.org)
- Automation of build-machine configuration with Ansible or whatever else floats your boat / is required by ASF Infra.
- Invent system to maintain and extend this going forward, with new operating system releases and Erlang versions being released.
- Set up newly minted build-machines with either ci.apache.org or ci.couchdb.org:8888 Jenkins installs (ci.apache.org preferred)

This is already a bit of work. I’d recommend to start small:

1. Get one OS in a single configuration going (maybe even just current Ubuntu and latest-ish Erlang).
2. Go through the whole process and see it running on master and our test branches, set up all the integrations (Github/IRC/Email) etc. just to see that we have a full system running, from build-machine config to succeeding builds.
3. Only then, start extending to multiple OSs and configurations (of course, if you can roll some work for this into step 1., don’t hold off on it, but this is only crucial at a later state).


* * * 

## Configurations

A small sidebar on configurations: the most interesting build variation is different Erlang versions. CouchDB supports quite a wide range of Erlang versions (R14B01|R14B03|R14B04|R16B02|R16B03-1|17), and eventually it’d be nice to test against the whole range, or at least the last in a major release line. Erlang also releases preview versions of upcoming major versions frequently and being up to speed what is going to happen would be nice.

Most other CouchDB dependencies are rather stable. At this point we mostly run on SpiderMonkey 1.8.5 and whatever is the latest ICU (icu4c) release, but some variation there would be nice as well. Other devs, what am I missing?

As for operating systems, like mentioned in the wiki link above, it’d be nice to arrive at a policy where we support all current and LTS releases of Linux distros/FreeBSD/*BSD/{Solaris,Illumos}/Windows/etc. If we get to it, even latest-1 versions. Also interesting are non-x86/ia64 architectures, especially embedded ARM things like RasPI. All this is nice to have for *way* later, just so you have an idea where this is going.

* * *

One last thing that we also want to get going eventually is release channels for the various package management systems where the Apache CouchDB Project maintains releases in that channel. Ideally, they are built and tested on our CI infrastructure on each platform/version configuration and ideally of of this is automated, with testing and stable channels, so people can test in-development versions for CouchDB really easily. All this should make CouchDB a lot easier to install on various platforms. But again, this is a little off, and not a primary goal just yet.

* * *

Okay, that’s it for now. I hope you are still with me! :)

Thank you Francis and Bastian (in CC) for responding to the call to action last week and Dominik, who voiced interest in this at the CouchDB Day in Hamburg earlier this year. I’ll be pointing more folks to this mailing list post, so I hope we’ll get some more to join.

If you know anyone partial to these topics, please point them here as well!

If you have any questions, feel free to ask here or on Freenode IRC #couchdb or #couchdb-dev, but for now, the mailing list is probably best, with IRC being reserved for hashing out details that need higher bandwidth.

Thanks for reading and I hope we can get this off the ground! :)

Best
Jan
-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Re: Continuous Integration Redux

Posted by Dave Cottlehuber <dc...@apache.org>.
On Sat, 4 Jul 2015, at 12:38 AM, Bastian Krol wrote:
> >> BTW, where could we put this code? I believe the ASF has its own git infrastructure, right?
> >
> > You can request couchdb-ci git repo for you. It’ll be mirrored to GitHub under github.com/apache/couchdb-ci, so you can do PRs as normal(-ish) here: https://issues.apache.org/jira/servicedesk/customer/portal/1 (set the mailing list to notifications@couchdb.apache.org
> 
> For what it's worth, the current work in progress is here: 
> https://github.com/basti1302/couchdb-ci , just in case someone wants to 
> hop on the band wagon :)
> 
> Dominik, Francis, any plans for getting on board?
> 
> Ultimately the code will live at 
> http://git-wip-us.apache.org/repos/asf/couchdb-ci.git, and will be 
> mirrored to https://github.com/apache/couchdb-ci.
> 
> Right now, there is just a rudimentary Ansible script that installs 
> Jenkins and nginx, a Veewee definition for an Ubuntu base box, and a 
> Vagrantfile to test drive the Ansible scripts locally.


Bastian, this sounds great. I'm happy to help out in any way. Also, we
have a couchdb-vm which runs Ubuntu, this might be useful too. See
https://github.com/dch/couchdb-vm for some more notes if that helps.

A+
Dave

Re: Continuous Integration Redux

Posted by Jan Lehnardt <ja...@apache.org>.
> On 04 Jul 2015, at 00:38, Bastian Krol <ba...@tu-dortmund.de> wrote:
> 
>>> BTW, where could we put this code? I believe the ASF has its own git infrastructure, right?
>> 
>> You can request couchdb-ci git repo for you. It’ll be mirrored to GitHub under github.com/apache/couchdb-ci, so you can do PRs as normal(-ish) here: https://issues.apache.org/jira/servicedesk/customer/portal/1 (set the mailing list to notifications@couchdb.apache.org
> 
> For what it's worth, the current work in progress is here: https://github.com/basti1302/couchdb-ci , just in case someone wants to hop on the band wagon :)
> 
> Dominik, Francis, any plans for getting on board?
> 
> Ultimately the code will live at http://git-wip-us.apache.org/repos/asf/couchdb-ci.git, and will be mirrored to https://github.com/apache/couchdb-ci.
> 
> Right now, there is just a rudimentary Ansible script that installs Jenkins and nginx, a Veewee definition for an Ubuntu base box, and a Vagrantfile to test drive the Ansible scripts locally.
> 
> @Jan: I'd still would like to have a look at the current setup at ci.couchdb.org.

Sorry for the delay, do you have an account on http://ci.couchdb.org:8888 yet? If not, can you make one, tell me the username, and then I’ll assign the required permissions to your account.

Thanks!
Jan
--

> 
> Kind regards
> 
>  Bastian

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Re: Continuous Integration Redux

Posted by Bastian Krol <ba...@tu-dortmund.de>.
>> BTW, where could we put this code? I believe the ASF has its own git infrastructure, right?
>
> You can request couchdb-ci git repo for you. It’ll be mirrored to GitHub under github.com/apache/couchdb-ci, so you can do PRs as normal(-ish) here: https://issues.apache.org/jira/servicedesk/customer/portal/1 (set the mailing list to notifications@couchdb.apache.org

For what it's worth, the current work in progress is here: 
https://github.com/basti1302/couchdb-ci , just in case someone wants to 
hop on the band wagon :)

Dominik, Francis, any plans for getting on board?

Ultimately the code will live at 
http://git-wip-us.apache.org/repos/asf/couchdb-ci.git, and will be 
mirrored to https://github.com/apache/couchdb-ci.

Right now, there is just a rudimentary Ansible script that installs 
Jenkins and nginx, a Veewee definition for an Ubuntu base box, and a 
Vagrantfile to test drive the Ansible scripts locally.

@Jan: I'd still would like to have a look at the current setup at 
ci.couchdb.org.

Kind regards

   Bastian

Re: Continuous Integration Redux

Posted by Jan Lehnardt <ja...@apache.org>.
> On 01 Jul 2015, at 08:50, Bastian Krol <ba...@tu-dortmund.de> wrote:
> 
> Hey folks!
> 
> So let's try to get this discussion started. I'll just throw in some half baked ideas here :-)
> 
> I really like the idea of having all the setup of the Jenkins machines, especially the slaves, as code in Ansible or something similar. We need to decide on a tool here. Obvious candidates are Ansible, Puppet and Chef. I definitely prefer Ansible over the other two (having worked both with Ansible and Puppet, but not Chef). However, for some tasks (like installing packages) Puppet offers a slightly higher level of abstraction than Ansible. This could have advantages when supporting a lot of OSes in the end. Opinions?
> 
> I also would like to be able to spin up these boxes locally as a virtual box to test them. In another projects we did this by combining Ansible with Vagrant, we also used Veewee (https://github.com/jedi4ever/veewee) to configure the base boxes. I could come up with a similar setup for the first box relatively quick, I think.
> 
> If everything is scripted and automated, it is also much easier to switch from one infrastructure to another.

This sounds all good :)

> BTW, where could we put this code? I believe the ASF has its own git infrastructure, right?

You can request couchdb-ci git repo for you. It’ll be mirrored to GitHub under github.com/apache/couchdb-ci, so you can do PRs as normal(-ish) here: https://issues.apache.org/jira/servicedesk/customer/portal/1 (set the mailing list to notifications@couchdb.apache.org


> One thing I'm really unsure right now: Does our "vision" align with ci.apache.org? From what I read at http://ci.apache.org/#jenkins / https://builds.apache.org/ there seems to be a certain gap, namely:
> 
> * They do not have all OSes that we would like to support in the end, for example Ubuntu seems to be the only Linux flavor. OTOH, they do have quite a few (Solaris, FreeBSD, some Windows).
> * How would installing different versions of Erlang work with infrastructure that we (the CouchDB project) do not control completely?
> * The Jenkins machines and the slave seem to be maintained manually, so if we want to do a fully automated set up of the build/test slaves (like, with Ansible) this might be a conflict.

In general, ASF Infra is there to support individual projects like Apache CouchDB. If we have new requirements, no currently covered by existing infrastructure, then we need to work with the Infra team on how to get this going. I think what we need is fairly vanilla CI setup, but it looks like the general CI infra is a bit Java heavy (as is the ASF ;), so there might be some work for us to do.

E.g. we wanted to move to git for version control, so Paul Davis from the CouchDB team worked with Infra on how to solve this ASF-wide. I envision a similar collaboration, at least in the beginning between the CouchDB CI team and the ASF Infra CI teams.

> All these are just guesses and speculations, so, of course, we really need to talk it through with the ASF Infra/CI team. I would like to talk to them *after* we have come to a shared understanding of what we want to do.

Just repeating what you said, I agree that this sounds like a good plan of action:
1. find out what we want.
2. talk to ASF Infra on how we can get it going.
3. Profit.

Thanks for taking the lead here, Bastian! :)

Best
Jan
--

> 
> Best regards
> 
>  Bastian

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Re: Continuous Integration Redux

Posted by Bastian Krol <ba...@tu-dortmund.de>.
Hey folks!

So let's try to get this discussion started. I'll just throw in some 
half baked ideas here :-)

I really like the idea of having all the setup of the Jenkins machines, 
especially the slaves, as code in Ansible or something similar. We need 
to decide on a tool here. Obvious candidates are Ansible, Puppet and 
Chef. I definitely prefer Ansible over the other two (having worked both 
with Ansible and Puppet, but not Chef). However, for some tasks (like 
installing packages) Puppet offers a slightly higher level of 
abstraction than Ansible. This could have advantages when supporting a 
lot of OSes in the end. Opinions?

I also would like to be able to spin up these boxes locally as a virtual 
box to test them. In another projects we did this by combining Ansible 
with Vagrant, we also used Veewee (https://github.com/jedi4ever/veewee) 
to configure the base boxes. I could come up with a similar setup for 
the first box relatively quick, I think.

If everything is scripted and automated, it is also much easier to 
switch from one infrastructure to another.

BTW, where could we put this code? I believe the ASF has its own git 
infrastructure, right?

One thing I'm really unsure right now: Does our "vision" align with 
ci.apache.org? From what I read at http://ci.apache.org/#jenkins / 
https://builds.apache.org/ there seems to be a certain gap, namely:

* They do not have all OSes that we would like to support in the end, 
for example Ubuntu seems to be the only Linux flavor. OTOH, they do have 
quite a few (Solaris, FreeBSD, some Windows).
* How would installing different versions of Erlang work with 
infrastructure that we (the CouchDB project) do not control completely?
* The Jenkins machines and the slave seem to be maintained manually, so 
if we want to do a fully automated set up of the build/test slaves 
(like, with Ansible) this might be a conflict.

All these are just guesses and speculations, so, of course, we really 
need to talk it through with the ASF Infra/CI team. I would like to talk 
to them *after* we have come to a shared understanding of what we want 
to do.

Best regards

   Bastian

Re: Continuous Integration Redux

Posted by Jan Lehnardt <ja...@apache.org>.
> On 30 Jun 2015, at 14:49, Bastian Krol <ba...@tu-dortmund.de> wrote:
> 
>> We can’t use GH issues yet, for the moment we are restricted to JIRA: https://issues.apache.org/jira/browse/COUCHDB (sorry :)
> 
> That's fine, too.
> 
>> What we can do is create a separate mailing list for you, if you feel better not discussing this on dev@, but you are more than welcome to discuss things here.
> 
> As long as it does not bother the mailing list (like, too much traffic or whatever) dev@ is just fine.

Definitely no bother :)

Best
Jan
--

> 
> Kind regards
> 
>  Bastian

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Re: Continuous Integration Redux

Posted by Bastian Krol <ba...@tu-dortmund.de>.
> We can’t use GH issues yet, for the moment we are restricted to JIRA: https://issues.apache.org/jira/browse/COUCHDB (sorry :)

That's fine, too.

> What we can do is create a separate mailing list for you, if you feel better not discussing this on dev@, but you are more than welcome to discuss things here.

As long as it does not bother the mailing list (like, too much traffic 
or whatever) dev@ is just fine.

Kind regards

   Bastian

Re: Continuous Integration Redux

Posted by Jan Lehnardt <ja...@apache.org>.
> On 30 Jun 2015, at 12:11, Bastian Krol <ba...@tu-dortmund.de> wrote:
> 
> Hey folks,
> 
> so, how and where do we start?
> 
> I guess we need some initial discussion on how to structure the CI system. Maybe we can start this discussion via mail or have an initial hangout or something.
> 
> I also think that we need to find a way to organize our efforts. I guess some kind of task tracking would be helpful. Maybe one of the CouchDB devs with sufficient privileges could set up a dedicated GitHub repo where we can start to break the work down into tasks? (something like https://github.com/apache/couchdb-continuous-integration)

We can’t use GH issues yet, for the moment we are restricted to JIRA: https://issues.apache.org/jira/browse/COUCHDB (sorry :)

What we can do is create a separate mailing list for you, if you feel better not discussing this on dev@, but you are more than welcome to discuss things here.


> @Jan: Would it be possible to give us access to http://ci.couchdb.org:8888 (Jenkins web UI, shell) to have a look at the current setup?

Yeah, will do tonight.

Best
Jan
--


> 
> Kind regards
> 
>  Bastian

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Re: Continuous Integration Redux

Posted by Bastian Krol <ba...@tu-dortmund.de>.
Hey folks,

so, how and where do we start?

I guess we need some initial discussion on how to structure the CI 
system. Maybe we can start this discussion via mail or have an initial 
hangout or something.

I also think that we need to find a way to organize our efforts. I guess 
some kind of task tracking would be helpful. Maybe one of the CouchDB 
devs with sufficient privileges could set up a dedicated GitHub repo 
where we can start to break the work down into tasks? (something like 
https://github.com/apache/couchdb-continuous-integration)

@Jan: Would it be possible to give us access to 
http://ci.couchdb.org:8888 (Jenkins web UI, shell) to have a look at the 
current setup?

Kind regards

   Bastian

Re: Continuous Integration Redux

Posted by Bastian Krol <ba...@tu-dortmund.de>.
Hi folks,

here is the issue in the ASF Jira for discussing the issue with the ASF 
infra team:

https://issues.apache.org/jira/browse/INFRA-10126

Kind regards

   Bastian

Re: Continuous Integration Redux

Posted by Adam Kocoloski <ko...@apache.org>.
Great stuff Jan. I’ve forwarded to some of our internal CI team who might not be watching this list on a daily basis.

Your comments about non-x86 architectures also resonate, as we get relatively frequent requests to support Cloudant on the POWER architecture, and I’ve convinced IBM to donate hardware to the ASF CI system as a stepping stone there :) Cheers,

—
Adam Kocoloski
IBM Distinguished Engineer
CTO, Cloud Data Services

> On Jun 29, 2015, at 5:21 PM, Jan Lehnardt <ja...@apache.org> wrote:
> 
> Hey all,
> 
> last week I did a bit of outreach on Twitter, trying to grow our CI team. “What CI team?” you ask. — Exactly.
> 
> CouchDB needs world-class continuous integration in order to guarantee that we deliver quality software across many platforms and configuration without wasting too much time.
> 
> In the past, I’ve handled the CI setup (http://ci.couchdb.org:8888 / rough docs at: http://wiki.apache.org/couchdb/CI where you see that we are a little out of date ;) on a Mac Mini in my home. It was meant as a temporary measure until a larger team could take over. This never happened and we are trying to revive the effort now for the upcoming 2.0 release.
> 
> Before you ask: we are already using Travis CI, and it is really nice to do baseline checks for ongoing development and Pull Requests, but it is inadequate to satisfy all our testing needs. In particular testing on multiple operating systems, different operating system versions, dependency versions and configurations (and Windows!) — I’m very good personal friends with the Travis team, and they want to work towards supporting these things, but it’s nowhere near on their roadmap, and we need better CI now.
> 
> 
> ## There are a bunch of things to do
> 
> Before I go into details, I’d like to point out that the most important thing we need here is someone, or better a group of people that are *interested in assuming ownership of the CouchDB Continuous Integration operations*. 
> 
> You’ll be part of a uniquely friendly community and would work on something, while sometimes thankless, that would be of incredible benefit to the project. And we are here to hold your hands getting started. :)
> 
> Also, nothing here requires any specific Erlang knowledge. Any test suites are up to the Erlang devs in the community and other than that, Erlang is just another Unix/Windows binary, nothing special required, *and* you have a bunch of experts eager to help you at your disposal :)
> 
> And one final prelude item: While these things might seem overly specific, it doesn’t really matter how you arrive at what we need. One of the appeals of Open Source is to do your own thing and see that it helps, so if you have a completely different vision for CI that would give us the same or even better benefits, by all means, it’s your show :)
> 
> With all that out of the way, there are multiple areas that need tackling:
> 
> - Coordination with the ASF Infra/CI team for the existing Jenkins setup and build-machine configuration (we can continue to use ci.couchdb.org:8888 for a while but eventually, this should live on ci.apache.org)
> - Automation of build-machine configuration with Ansible or whatever else floats your boat / is required by ASF Infra.
> - Invent system to maintain and extend this going forward, with new operating system releases and Erlang versions being released.
> - Set up newly minted build-machines with either ci.apache.org or ci.couchdb.org:8888 Jenkins installs (ci.apache.org preferred)
> 
> This is already a bit of work. I’d recommend to start small:
> 
> 1. Get one OS in a single configuration going (maybe even just current Ubuntu and latest-ish Erlang).
> 2. Go through the whole process and see it running on master and our test branches, set up all the integrations (Github/IRC/Email) etc. just to see that we have a full system running, from build-machine config to succeeding builds.
> 3. Only then, start extending to multiple OSs and configurations (of course, if you can roll some work for this into step 1., don’t hold off on it, but this is only crucial at a later state).
> 
> 
> * * * 
> 
> ## Configurations
> 
> A small sidebar on configurations: the most interesting build variation is different Erlang versions. CouchDB supports quite a wide range of Erlang versions (R14B01|R14B03|R14B04|R16B02|R16B03-1|17), and eventually it’d be nice to test against the whole range, or at least the last in a major release line. Erlang also releases preview versions of upcoming major versions frequently and being up to speed what is going to happen would be nice.
> 
> Most other CouchDB dependencies are rather stable. At this point we mostly run on SpiderMonkey 1.8.5 and whatever is the latest ICU (icu4c) release, but some variation there would be nice as well. Other devs, what am I missing?
> 
> As for operating systems, like mentioned in the wiki link above, it’d be nice to arrive at a policy where we support all current and LTS releases of Linux distros/FreeBSD/*BSD/{Solaris,Illumos}/Windows/etc. If we get to it, even latest-1 versions. Also interesting are non-x86/ia64 architectures, especially embedded ARM things like RasPI. All this is nice to have for *way* later, just so you have an idea where this is going.
> 
> * * *
> 
> One last thing that we also want to get going eventually is release channels for the various package management systems where the Apache CouchDB Project maintains releases in that channel. Ideally, they are built and tested on our CI infrastructure on each platform/version configuration and ideally of of this is automated, with testing and stable channels, so people can test in-development versions for CouchDB really easily. All this should make CouchDB a lot easier to install on various platforms. But again, this is a little off, and not a primary goal just yet.
> 
> * * *
> 
> Okay, that’s it for now. I hope you are still with me! :)
> 
> Thank you Francis and Bastian (in CC) for responding to the call to action last week and Dominik, who voiced interest in this at the CouchDB Day in Hamburg earlier this year. I’ll be pointing more folks to this mailing list post, so I hope we’ll get some more to join.
> 
> If you know anyone partial to these topics, please point them here as well!
> 
> If you have any questions, feel free to ask here or on Freenode IRC #couchdb or #couchdb-dev, but for now, the mailing list is probably best, with IRC being reserved for hashing out details that need higher bandwidth.
> 
> Thanks for reading and I hope we can get this off the ground! :)
> 
> Best
> Jan
> -- 
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>