How Cloud Foundry is Developed

I will briefly talk about the development of Cloud Foundry (CF), the features of the open source model and some personal experience.

In 2013, I became an active user of the platform when IBM launched Bluemix's internal beta, earlier this year I took part in porting Cloud Foundry to the POWER8 architecture , and from mid-October I became a member of the CF core team, passing the CF Dojo. But first things first.

I will not delve into the story or explain what Cloud Foundry is, but here is a necessary minimum of facts. CF is Platform as a Service (PaaS), developed by VMWare and later transferred by Pivotal Software. The source code has been opened , now there is still a separate incubator for CF projects. A little later, the Cloud Foundry Foundation was created, which included Pivotal, IBM, VMWare, EMC, GE, Intel, SAP, and currently includes more than 50 organizations . Initially, the platform was written in Ruby, later some of the components were rewritten to Go.

Now I will continue my story. In the spring, we already had a slightly working version of CF on POWER8 and we decided to share our code with the community. We made a pull request for one of the components ( BOSH ) and waited. But nothing happened. I had some experience in developing OpenStack and everything was more alive there, sooner or later someone came to your patch in Gerrit, commented, rated, you updated the patch, a couple of months - and your two lines are upstream! If lucky, it was possible to catch a couple of weeks. In general, we began to understand and understand the following.
')
CF uses another open source model. If everyone in OpenStack, from beginner to PTL, sends their review code to Gerrit, collect their two +2 from core team members and are trying not to get -1 from the rest, then there are two access levels in CF. There is a core team working full-time on specific tasks, for example, the BOSH team tracker . These are employees of companies belonging to the Cloud Foundry Foundation, some of them have direct access to the git repository. The rest work through pull requests, some of which are processed faster than the usual ones; I’ll explain why below. There is no formal code review system for the same reason.

The fact is that CF uses an agile process, the main elements of which are TDD and pair programming. Yes, pair programming, remember XP? Not Windows XP, but eXtreme Programming. Core team works this way and this model is recommended for the whole community. Obviously, this places specific requirements for individual contributors, so the CF team puts on learning and trust, rather than filtering through code review. For this, the Cloud Foundry Dojo program was created.

Dojo is a place where the Japanese are engaged in martial arts, but there is no need to fight in CF Dojo. This program is open to community members, participation is free. The program itself is extremely simple - a new developer (preferably a pair) for at least 6 weeks works together with members of the CF team. After 3 weeks, he or she receives feedback from new colleagues about what can be improved; after 6 weeks, if the team sees progress, he or she receives a black belt. Actually does not receive. He gets some credibility and changes from this developer are much faster accepted by the team, moreover, he or she becomes part of the team and can work on common tasks.

I passed CF Dojo at the Pivotal office in San Francisco. Another room recently opened EMC in Cambridge, Massachusetts. IBM soon opens its in Research Triangle Park . Usually you work in one team, in my case it was BOSH, the component managing the cluster. Commands standard size, 6-12 developers, one product manager. There is a rotation between the teams, so there is an elder - an anchor, a developer who rarely (or never) leaves the team. The week starts with the Iteration Planing Meeting (IPM), ends with the Retrospective Meeting. On the first, the product manager tells what needs to be done, on the second, the team says what went wrong and what was done correctly. Every day begins with a Standup Meeting, where everyone tells what was done yesterday, what will happen today and what problems there are. In general, more or less the usual Scrum. On the standup command is divided into pairs.



A couple sits down for a couple of poppies that behave like one. All machines in the office of the same configuration, almost no personal. Many developers have their own keyboard, otherwise everything is common, such a Zen. A couple takes the first free story (user story) from the tracker and starts, no, not to write code. First, tests are written, usually unit, but often integration. Then the code is written. The code should solve the problem minimally and pass the tests. Then refactoring is done so that it is not a shame. As a result, the changes are commited directly, without code review. They are picked up by CI (using its own development Concourse and some Jenkins, if you are interested in writing your own, read ). If the code did not pass pipeline, the couple makes corrections. When everything turns green, the story is sent to the product manager, who can accept it or return it for revision. As a result, the changes fall into the next version of the component, which is created every few days. Couples change every 1-3 days, sometimes a change happens when work on the story is not finished. There is also no specialization of developers, for example, someone is only engaged in OpenStack, and someone AWS - this is not in principle, the stories are distributed quite randomly. One day you write on Ruby, tomorrow on Go, then you edit shell scripts for CI or you configure AWS.

I tried to describe everything briefly, there are still many colorful details, but they are not so interesting to everyone, I can answer specific questions. As you can see, the CF model requires a much deeper immersion, deliberately sacrificing mass. Each approach has its pros and cons. Of course, this does not mean that for weekend warriors it is impossible to take part in the development of CF, read the code, find the tasks and send pull requests.