It is ready to be given a try, and it is still under change and
OK thanks so much for all the detailed info you've included here. I'll dig
into it and will report back here for any questions or issues.
I would love to get to a world that deploying CF is so easy that the
public documentation suffices for any individual team to set up their own
+1 from me :) as IMO that's key for growth and traction in a public and
On Wed, Oct 7, 2015 at 8:32 PM, Amit Gupta <agupta(a)pivotal.io> wrote:
Yes and yes. It is ready to be given a try, and it is still under change
and development. There are several tools in mega-ci:
1. provision AWS for BOSH and Concourse (and optionally CF), and deploy
2. deploy Concourse into that environment
3. provision AWS for BOSH and CF (without Concourse), and deploy BOSH.
The "provision AWS" parts are done via CloudFormation templates. I'm not
sure how to characterize the dependency on AWS API there, but the
CloudFormation templates have a format version, and we currently use the
only valid format, which has been stable for 5 years:
Tools 1 (
and 2 (https://github.com/cloudfoundry/mega-ci/#deploying-concourse)
mentioned above get you a concourse ready to run builds that deploy CF.
Depending on how well you understand AWS, BOSH, Concourse, and CF, the
pipeline config ymls and CI scripts in the same mega-ci repo can be
modified and used to continuously deploy CF to your environment. But they
are not ideal for the onboarding experience.
As for your point about whether other projects have to figure out
individually how to operate CI builds, that's a very poignant question.
Currently, the answer is yes. There is a dojo program designed to allow
people in the foundation to pair with the core teams to learn the system,
CI practices, etc. I would love to get to a world that deploying CF is so
easy that the public documentation suffices for any individual team to set
up their own CI easily.
Among the 20 or so core development teams, distributed around the world,
comprised of 100+ developers from several different companies, there
actually is a fairly robust, well integrated set of tools and practices
around CI and how we consume and produce assets for other pipelines. As
the foundation grows, the onboarding story will need to be improved. But
this is no small problem.
There are 100s of v219+ builds happening every day (and next week, there
will be v220+ builds). For now, I'd recommend opening up mailing list
issues or Github issues (e.g. here:
https://github.com/cloudfoundry/cf-release/issues) with the specific
errors you're encountering, the core development teams are happy to help
the community past the initial technical and conceptual bootstrapping
And to address your question about the financials, I don't know the
complete picture, but the question "who foots the bills for all the current
CIs?" and "who should foot the bill for a publicly available pool of CI
environments?" probably have different answers.
Amit, OSS Release Integration PM
On Wed, Oct 7, 2015 at 3:48 PM, Jean-Sebastien Delfino <
We're working on making deploying CF itself less burdensome, but thatwill take more time.
Is that tooling  ready for use? In other words is it ready for me to
give it a try, or is still under dev?
How strong is the dependency on the AWS API?
As for having someone actually maintain CF environments for thecommunity or dev teams to checkout and use as a service, the question is,
who foots the bill?
There's obviously a lot that I don't know yet about the CF community as a
new kid on the block here, but I see that we have a common CF mailing list
infra, common Github org and repos, some Web sites, some governance. So for
me, naively, the next logical thing to look for as a resource operated by
and for the CF community, was... a common build infra for the CF projects
to share :) Who foots the bill for the other existing CF common resources?
On Tue, Oct 6, 2015 at 9:03 AM, Amit Gupta <agupta(a)pivotal.io> wrote:
The CF OSS Release Integration team (aka MEGA) is working on tooling to
fully bootstrap an AWS VPC with BOSH and Concourse running, and sufficient
AWS resources (eg subnets, ELB) to deploy CF:
We're working on making deploying CF itself less burdensome, but that
will take more time.
As for having someone actually maintain CF environments for the
community or dev teams to checkout and use as a service, the question is,
who foots the bill?
On Tuesday, October 6, 2015, Michael Maximilien <mmaximilien(a)gmail.com>
Chiming in with some info and to add to Sebastien's request.
While most of the teams in CF have switched to using concourse for
their pipelines. And each pipeline instantiation has to be built and manage
individually. The issue mentioned here, needing to provision latest CF
releases to use for testing apps, services, brokers, etc is a real one. And
likely one many solve also individually.
Begs the question whether it should be offered as a service for all to
use. Almost like "CF as a Service" type of service broker... Just thinking
out loud here. Cloud capacity and managing resources would be the long
running costs after initial investment.
Sent from Mailbox <https://www.dropbox.com/mailbox>
On Mon, Oct 5, 2015 at 7:27 PM, Jean-Sebastien Delfino <
So far in the Abacus project we've been running our automated tests
outside CF (as our Node.js apps can also run outside with just a bit of env
variable config) on Travis-CI. Some of us also deploy our apps to Bosh lite
to test inside CF but maintaining working versions of Bosh lite is pretty
time consuming and that manual testing hasn't been a repeatable process so
far, so I'd really like to automate that with a proper CI build and test
Are there any CF deployment environments available for CF incubating
projects to use for CI builds and tests?
I'm looking for an environment where my build script could simply
select a specific version of CF, bootstrap it 'clean' (nothing left over
from previous runs), deploy the Abacus apps to it to run the tests there,
then repeat with a different version of CF etc.
Is anything like that already available for CF projects to use?