How Cloud Foundry is being developed

    CF community logoI’ll briefly talk about the Cloud Foundry (CF) development process , the features of the open source model, and some personal experience.

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

    I will not go deep into history or explain what Cloud Foundry is, but here is the necessary minimum of facts. CF is Platform as a Service (PaaS) developed by VMWare and later transferred to Pivotal Software. The source code was open , now there is still a separate incubatorCF projects. A little later, the Cloud Foundry Foundation was created , which included the Pivotal, IBM, VMWare, EMC, GE, Intel, SAP, and now it includes more than 50 organizations . Initially, the platform was written in Ruby, later some of the components were rewritten in 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. Made a pull request for one of the components ( BOSH) and began to wait. But nothing happened. I had some experience in developing OpenStack and everything was livelier 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 in the upstream! If you were lucky, then you could have time for a couple of weeks. In general, we began to understand and understood the following.

    CF uses a different open source model. If in OpenStack, everything from a newbie to PTL sends their code for review to Gerrit, collects their two +2 from core team members, and tries not to get -1 from the rest, then CF has two levels of access. There is a core team working full time on specific tasks, for example, the BOSH team tracker. These are employees of companies within the Cloud Foundry Foundation, some of which have direct access to the git repository. The rest work through pull requests, some of which are processed faster than regular ones, I will 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. This is how the core team works and this model is recommended for the entire community. Obviously, this makes specific demands on individual contributors, so the CF team places on training and trust, not filtering through code review. For this, the Cloud Foundry Dojo program was created.

    Dojo- This is a place where the Japanese practice martial arts, but you don’t have to fight at CF Dojo. This program is open to community members, participation is free. The program itself is extremely simple - the new developer (preferably a couple) works with CF team members for at least 6 weeks. 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. Not really getting it. Gets some credit of trust 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 went through CF Dojo at the Pivotal office in San Francisco. Another hall recently opened EMC in Cambridge, Massachusetts. IBM opens soon inResearch Triangle Park . Usually you work in one team, in my case it was BOSH, the component managing the cluster. Standard size teams, 6-12 developers, one product manager. There is a rotation between the teams, so there is an elder - the anchor, a developer who rarely (or never) leaves the team. Week starts with Iteration Planing Meeting (IPM), ends with Retrospective Meeting. At the first, the product manager tells what needs to be done, at the second, the team says what went wrong and what was done correctly. Every day begins with a Standup Meeting, where everyone talks about what was done yesterday, what will happen today and what are the problems. In general, a more or less ordinary Scrum. At standup, the team is paired.



    A couple sits behind a pair of poppies that behave like one. All cars in the office have the same configuration, almost no personal ones. Many developers have their own keyboards, otherwise everything is common, such a Zen. The couple takes the first free story (user story) from the tracker and begins, no, not to write code. First, tests are written, usually unit, but often integration. Then the code is written. The code should minimize the problem and pass the tests. Then refactoring is done so that it is not a shame. As a result, changes are committed directly, without code review. They are picked up by CI ( Concourse's own development is used and a bit of Jenkins, if you wonder why you wrote your own, read) If the code did not pass the pipeline, the couple makes corrections. When everything turned 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 once every few days. Couples change once every 1-3 days, sometimes a change happens when the work on the story is not finished yet. There is also no specialization of developers, for example, someone is engaged only in OpenStack, and someone is AWS - this is not in principle, stories are distributed quite randomly. One day you write in Ruby, tomorrow on Go, then you edit shell scripts for CI or 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, consciously sacrificing mass. Each approach has its pros and cons. Of course, this does not mean that for the weekend warriors it is impossible to take part in CF development, read the code, find the tasks and send pull requests.

    Also popular now: