#build system

I've neglected to write about the *other* half of my team, not for any lack of desire to do so, but simply because the code sheriffing situation was taking up so much of my time. Now that the SoftVision contractors have gained the commit access required to be fully functional sheriffs, I feel that I can shift focus a bit.

Meet the team

The other half of my team consists of 4 Firefox build system peers. My team consists of:

Chris Manchester

Ted Mielczarek

Mike Shal

Greg Szorc

When the group was first established, we talked a lot about what we wanted to work on, what we needed to work on, and what we should be working on. Those discussions revealed the following common themes:

We have a focus on developers. Everything we work on is to help developers be more productive, and go more quickly.

We accomplish this through tooling to support better/faster workflows.

Some of these improvements can also assist in automation, but that isn't our primary focus, except where those improvements are also wins for developers, e.g. faster time to first feedback on commit.

We act as consultants/liaisons to many other groups that also touch the build system, e.g. Servo, WebRTC, NSS etc.

Based on that list of themes, we've adopted the moniker of "Developer Workflow." We are all build peers, yes, but to pigeon-hole ourselves as the build system group seemed short-sighted. Our unique position at the intersection of the build system, VCS, and other services meant that our scope needed to match what people expect of us anyway.

While new to me, Developer Workflow is a logical continuation of build system tiger team organized by David Burns in 2016. This is the same effort that yielded sea change improvements such as artifact builds and sccache.

In many ways, I feel extremely fortunate to be following on the heels of that work. During the previous year, all the members of my team formed the working relationships they would need to be more successful going forward. All the hard work for me as their manager was already done! ;)

What are we doing

We had our first, dedicated work week as a team last week in Mountain View. Aside from getting to know each other a little better, during the week we hashed out exactly what our team will be focused on next year, and made substantial progress towards bootstrapping those efforts.

Next year, we'll be tackling the following projects:

Finish the migration from Makefiles to moz.build files: A lot of important business logic resides in Makefiles for no good reason. As someone who has cargo-culted large portions of l10n Makefile logic during my tenure at Mozilla, I may be part of the problem.

Move build logic out of *.mk files: Greg recently announced his intent to remove client.mk, a foundational piece of code in the Mozilla recursive make build system that has existed since 1998. The other .mk files won't be far behind. Porting true build logic to moz.build files and removing non-build tasks to task-based scripts will make the build system infinitely more hackable, and will allow us to pursue performance gains in many different areas. For example, decoupled tests like package tests could be run asynchronously, getting results to developers more quickly.

Stand-up a tup build in automation: this is our big effort for the near-term. A tup build is not necessarily an end goal in-and-of itself — we may very well end up on bazel or something else eventually — but since the Mike Shal created tup, we control enough of the stack to make quick progress. It's a means of validating the Makefile migration.

Move our Linux builder in automation from Centos6 to Debian: This would move move us closer to deterministic builds, and has alignment with the TOR project, but requires we host our own package servers, CDN, etc. This would also make it easier for developers to reproduce automation builds locally. glandium has a proof-of-concept. We hope to dig into any binary compatibility issues next year.

Weening off mozharness for builds: mozharness was a good first step at putting automated build configuration information in the tree for developers. Now that functionality could be better encapsulated elsewhere, and largely hidden by mach. The ultimate goal would be to use the same workflow for developer builds and automation.

What are we *not* doing

It's important to be explicit about things we won't be tackling too, especially when it's been unclear historically or where there might be different expectations.

The biggest one to call out here is github integration. Many teams at Mozilla are using github for developing standalone projects or even parts of Firefox. While we've had some historical involvement here and will continue to consult as necessary, other teams are better positioned to drive this work.

Those who want to know regarding CentOS server support, we have gossip for you. Open documentation CentOS Linux 7 OS is now available, at minority group officially. It offers a free alternative for the CentOS server administrators who do not need or be desirous of a commercial design Linux distribution that is totally supported. <\p>

CentOS 7 is a trimmed form of Community ENTerprise Operating System 7 and a Linux distribution that comes free and is community-supported. This distribution is based on Red Hat Enterprise Linux field RHEL 7 operating system that has become officially available since June 10.<\p>

The latest CentOS project integrates RHEL open-source code and no Red Hat trademarks are involved in its packaging. That brings us an in the works system which is free to second nature as well now obtain.<\p>

On the contrary, RHEL 7 released by Red Hat box up be availed on a device degree. Themselves is a model that provides industry-standard top-notch server administration service and support, certification, and tools apart out the server operating system itself. <\p>

There are several reasons why CentOS is as all creation notable. <\p>

€ First of all, it is the leading launch from the project following its being integrated by Red Coif. In conformity with issuing a statement in January this moon, Red Pillbox came up including an official announcement of their partnering with CentOS collectivity, starting all goodwill tech industry.<\p>

€ The second mention-worthy fact of CentOS 7 release is its speed factor right with which it has been made available. Good understanding November of 2011, RHEL debuted and accommodated to that waltz time, the CentOS project could not commend to attention frictionless CentOS 6 release and inner self came into the market only in July, 2012 - after a long hour of nine months. <\p>

€ CentOS is RHEL 7 based and integrates the same brine features including XFS filesystem (default system), providing a de novo filesystem towards the users. The new filesystem has scalability to 500 terabytes. <\p>

For seasonably CentOS versions, only ISO images were offered per the community groups. Now they usucapt a give being to to produce multiple images in lieu of close formation. Among those images is Docker as well as crowd images for RackSpace, Google Compute, Haploid and AWS. <\p>

Karanbir Singh, CentOS entrepreneur, squarely refined it clear in his nonpros announcement that the professionals are already working on a community join system that is likely to be made functional towards the end of July 2014. According to him, that untapped build will allow the convoy to develop a assignor base in Special Notice Groups for extension as well as create additional variants and layers on CentOS Linux. <\p>

Using Gradle In Your Command Line Android Project

I’ve been developing mobile Android applications since 2011 and up until now I’ve been using nothing but Apache Ant for building them.

Now you’re probably like, it is 2015, why aren’t you using Gradle like the rest of the world?  Well, I like Apache Ant, and I had no real reason to switch.  However, I’ve decided this is the year I jump ship.

If you’re like me, a no IDE rebel coming from an Apache…

전날 밤 J가 부탁한 빌드를 전달해 주지 못해, 휴일이지만 점심쯤 사무실에 들러 디버그 빌드를 J의 핸드폰에 넣어 주었다. 1) B와의 짝프로그래밍 과정이 지연되었고 2) 작업중인 내용에 버그가 있어, 중간에 릴리즈 빌드를 올릴 수 없었고 (B는 아직 git에 적응하는 중으로, 작업단위를 끊어서 커밋하는 습관을 체화하지 못하였다) 3) 빌드를 테스트 플라이트에 전달하는 일을 B에게 인계하였고 4) 퇴근 시간에 나보다 민감한 B에게 압박을 주고싶지 않았기에 5) J에게 급한 용무로 요청하지 않은 빌드라면 팀을 퇴근시키고 다음날 빌드를 전해주기로 했다.

유니티 라이센스와 빌드머신이 없어 마저 구성하지 못 했던 자동화 빌드 시스템을 구성해야 할 필요를 느낀다(팀이 느낄 수 있게 팀에게 빌드를 인계하는 과정에 있다. 다음 빌드요청이 온다면 B 혹은 A에게 그 책임을 바로 넘겨야겠다. 생각해보니 빌드를 관리하는 것은 A의 역할이니 A에게 인계해야겠다. 자동화 빌드시스템도 A에게..)

자동화 빌드 시스템을 아직 구축하지 못 한 것은 부끄럽지만, 그렇게 하기 위해 노력중이다. 한 달 전 이 팀에 합류했을 때, 버전관리 시스템조차 존재하지 않았고, 프로젝트를 파악하며 git을 팀에게 학습/변화 시키는 것이 우선이었다.

간단히 빌드를 전달해 준 뒤에는 로그서버로 활용하던 머신의 윈도우를 밀어버리고 리눅스ubuntu를 셋팅하였다. os 인스톨부터 리눅스를 사용하는 것은 처음이지만, 이후 퍼블리셔 측에 전달할 배포 가이드를 위해 직접 셋팅을 진행하였다. postgre와 ssh, 계정 권한설정 이후 python virtualenv를 사용하여 배포환경을 구분하고 있다. 일단 ssh 및 방화벽 설정을 마무리하고 좋은 날씨의 공휴일에 저녁약속을 잡고 사무실을 나왔다.

이번 하루는 또, 다른 이를 배려하느라 떠안은 일로 그리 기분이 유쾌하지만은 않은 하루였다. 더불어 배려하려 시작한 작업이 J가 당연하고 평등한 관계로 인식하고 응대해 옴에 기분이 좋지 않았다. - ‘사람을 걱정하는 것 보다 제품에 집중하는 것’, ‘순수한 열정을 가진 사람들과 함께하는 것’에 있어 ‘나를 포함하는’ 이 팀이 맞지 않다는 것을 느낀다. - ‘개발자로서의 자긍심’을 지키려 노력하고 있다. 아, 지금은 이 팀의 작업을 도와 마무리를 하고 있지만 공식적으로는 나는 이 팀의 외부인이다.