Engenharia de Release do FreeBSD (Legado)

O desenvolvimento do FreeBSD é um processo muito aberto. O FreeBSD é composto por contribuições de milhares de pessoas em todo o mundo. O Projeto FreeBSD fornece acesso ao Subversion ^[1] para o público em geral para que outros possam ter acesso a mensagens de log, diffs (patches) entre branches (ramificações) de desenvolvimento e outros aprimoramentos de produtividade que o gerenciamento formal de código-fonte proporciona. Isso tem sido uma grande ajuda na atração de desenvolvedores talentosos para o FreeBSD. No entanto, acho que todos concordariam que o caos logo se manifestaria se o acesso para modificar o repositório principal fosse aberto a todos na Internet. Dessa forma, apenas um grupo "seleto" de quase 300 pessoas recebe acesso de escrita ao repositório do Subversion. Estes committers ^[2] são normalmente as pessoas que fazem a maior parte do desenvolvimento do FreeBSD. Um Core team^[3] eleito fornece algum nível de orientação sobre o projeto.

O ritmo acelerado de desenvolvimento do FreeBSD torna a principal branch de desenvolvimento inadequada para o uso diário pelo público em geral. Em particular, são necessários esforços de estabilização para polir o sistema de desenvolvimento em uma release de qualidade apropriada para uso em ambiente produtivo. Para resolver este conflito, o desenvolvimento continua em várias trilhas paralelas. A principal branch de desenvolvimento é a HEAD ou trunk da nossa árvore do Subversion, conhecida como "FreeBSD-CURRENT" ou "-CURRENT" quando abreviado.

Um conjunto de branches mais estáveis é mantido, e é conhecido como "FreeBSD-STABLE" ou "-STABLE" na forma abreviada. Todas as branchs ficam em um repositório principal do Subversion mantido pelo Projeto FreeBSD. O FreeBSD-CURRENT é a "vanguarda do desenvolvimento tecnológico" do FreeBSD, pelo qual todas as novas alterações entram no sistema pela primeira vez. O FreeBSD-STABLE é a branch de desenvolvimento a partir do qual as releases principais são feitas. Mudanças entram nesta branch em um ritmo diferente, e com a suposição geral de que elas foram primeiro para o FreeBSD-CURRENT e foram exaustivamente testadas por nossa comunidade de usuários.

O termo stable no nome da branch refere-se à estabilidade presumida da Interface Binária da Aplicação (ABI), que é prometida pelo projeto. Isso significa que um aplicativo de usuário compilado em uma versão mais antiga do sistema da mesma branch funciona em um sistema mais novo da mesma branch. A estabilidade do ABI melhorou muito em relação às versões anteriores. Na maioria dos casos, os binários dos sistemas STABLE mais antigos são executados sem modificações em sistemas mais recentes, incluindo o HEAD, assumindo que as interfaces de gerenciamento do sistema não são usadas.

No período intermediário entre as versões, snapshots semanais são construídos automaticamente pelas máquinas de build do Projeto FreeBSD e disponibilizados para download em ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/. A ampla disponibilidade de snapshots binários e a tendência da nossa comunidade de usuários para acompanhar o desenvolvimento do -STABLE com o Subversion e "make buildworld" ^[4] ajuda a manter o FreeBSD-STABLE em uma condição muito confiável, mesmo antes que as atividades de garantia de qualidade aumentem na proximidade de um grande lançamento.

Além dos snapshots de instalação no formato ISO, imagens semanais de máquinas virtuais também são fornecidas para uso com o VirtualBox, o qemu ou outros softwares populares de emulação. As imagens de máquinas virtuais podem ser baixadas em ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/.

As imagens das máquinas virtuais tem aproximadamente 150MB compactadas com o xz(1) e contêm um sistema de arquivos esparso de 10GB quando atachado a uma máquina virtual.

Relatórios de bugs e solicitações de recursos são enviados continuamente pelos usuários durante todo o ciclo da release. Os relatórios de problemas são inseridos em nosso banco de dados do Bugzilla por meio da interface da Web disponibilizada em https://www.freebsd.org/support/bugreports/.

Para atender nossos usuários mais conservadores, versões individuais foram introduzidas com o FreeBSD 4.3. Estas branchs de versões são criadas pouco antes de uma liberação final ser feita. Após o lançamento, somente as correções e adições de segurança mais críticas são aplicadas na branch da versão. Além das atualizações do código fonte via Subversion, patchkits binários estão disponíveis para manter os sistemas nas branchs releng/X.Y atualizadas.

Novas versões do FreeBSD são liberadas a partir da branch -STABLE em intervalos de aproximadamente quatro meses. O processo de release do FreeBSD começa a se desenhar cerca de 70-80 dias antes da data de lançamento prevista, quando o engenheiro de versão envia um email para as listas de discussão de desenvolvimento para lembrar aos desenvolvedores que eles só têm 15 dias para integrar novas alterações antes do congelamento de código. Durante esse tempo, muitos desenvolvedores executam o que ficou conhecido como "MFC sweeps".

MFC significa "Merge From CURRENT" e descreve o processo de fusão de uma alteração testada de nossa branch de desenvolvimento -CURRENT com a nossa branch -STABLE. A política do projeto requer que qualquer mudança seja aplicada pela primeira vez ao trunk, e aplicada às branches -STABLE após testes externos suficientes serem feitos pelos usuários no -CURRENT (espera-se que os desenvolvedores testem extensivamente a mudança antes de enviarem a mesma para o -CURRENT, mas é impossível para uma pessoa exercer todos os usos de um sistema operacional de propósito geral). O período mínimo de MFC é de 3 dias, que normalmente é usado apenas para correções de bugs triviais ou críticas.

As "releases" do FreeBSD podem ser construídas por qualquer pessoa com uma máquina rápida e acesso a um repositório de código-fonte. (Isso deveria ser todo mundo, já que oferecemos acesso ao Subversion! Veja a seção sobre Subversion no Handbook para detalhes.) O único requisito especial é que o dispositivo md(4) esteja disponível. Se o dispositivo não estiver carregado em seu kernel, então o módulo do kernel deve ser carregado automaticamente quando o mdconfig(8) for executado durante a fase de criação da mídia de boot. Todas as ferramentas necessárias para construir uma release estão disponíveis no repositório Subversion em src/release. Essas ferramentas visam fornecer uma maneira consistente de construir versões do FreeBSD. Uma release completa pode ser construída com apenas um único comando, incluindo a criação de imagens ISO adequadas para gravação em CD-ROM ou DVD e um diretório para instalação por FTP. A pagina de manual release(7) documenta completamente o script src/release/generate-release.sh que é usado para construir uma release. O generate-release.sh é um invólucro em torno do target do Makefile: make release.

Embora o FreeBSD forme um sistema operacional completo, não há nada que force você a usar o sistema exatamente como o empacotamos para distribuição. Tentamos projetar o sistema para ser o mais extensível possível, de modo que ele possa servir como uma plataforma na qual outros produtos comerciais possam ser construídos. A única "regra" que temos sobre isso é que se você for distribuir o FreeBSD com mudanças não triviais, nós encorajamos você a documentar suas melhorias! A comunidade do FreeBSD só pode ajudar a suportar usuários do software que fornecemos. Nós certamente encorajamos a inovação na forma de ferramentas avançadas de instalação e administração, por exemplo, mas você não esperar que respondamos perguntas sobre isso.

O processo de engenharia de release do 4.4 começou formalmente em 1º de agosto de 2001. Após essa data, todos os commits da branch RELENG_4 do FreeBSD tiveram que ser explicitamente aprovados pela Equipe de Engenharia de Release re@FreeBSD.org. O primeiro release candidate para a arquitetura x86 foi lançado em 16 de agosto, seguido por mais 4 candidatos a versão que antecederam a versão final em 18 de setembro. O agente de segurança esteve muito envolvido na última semana do processo, pois vários problemas de segurança foram encontrados nos candidatos anteriores. Um total de mais de 500 e-mails foram enviados para a Equipe de Engenharia de Release re@FreeBSD.org em pouco mais de um mês.

Nossa comunidade de usuários deixou bem claro que a segurança e a estabilidade de uma versão do FreeBSD não devem ser sacrificadas por quaisquer prazos auto-impostos ou datas-alvo de lançamento. O projeto FreeBSD cresceu tremendamente ao longo de sua existência e a necessidade de procedimentos padronizados de engenharia de versões nunca foi tão aparente. Isso se tornará ainda mais importante à medida que o FreeBSD for portado para novas plataformas.

É imperativo que nossas atividades de engenharia de release sejam escaladas com nossa crescente base de usuários. Nessa linha, estamos trabalhando muito para documentar os procedimentos envolvidos na produção de versões do FreeBSD.

Eu gostaria de agradecer a Jordan Hubbard por me dar a oportunidade de assumir algumas das responsabilidades de engenharia de release do FreeBSD 4.4 e também por todo o seu trabalho ao longo dos anos fazendo do FreeBSD o que é hoje. É claro quea Release não teria sido possível sem todo o trabalho relacionado a release feito por Satoshi Asami asami@FreeBSD.org, Steve Price steve@FreeBSD.org, Bruce A. Mah bmah@FreeBSD.org, Nik Clayton nik@FreeBSD.org, David O’Brien obrien@FreeBSD.org, Kris Kennaway kris@FreeBSD.org, John Baldwin jhb@FreeBSD.org e o resto da comunidade de desenvolvimento do FreeBSD. Eu também gostaria de agradecer a Rodney Grimes rgrimes@FreeBSD.org, Poul-Henning Kamp phk@FreeBSD.org, e outros que trabalharam nas ferramentas de engenharia de release nos primeiros dias do FreeBSD. Este artigo foi influenciado por documentos de engenharia de release do CSRG ^[7], o Projeto NetBSD, ^[8], e as notas de processo de engenharia de release propostas por John Baldwin. ^[9]