O que exatamente são as "construções verdadeiramente reproduzíveis"?

O que exatamente eles são? Por que eles são importantes no domínio da Entrega Contínua?

Contexto: Eu vi em um dos comentários do (acho que o reddit) que as compilações verdadeiramente reproduzíveis ainda são uma tecnologia pouco pesquisada e é muito difícil de criar.

Então, eu queria saber por que eles são tão difíceis de criar?

O que exatamente eles são?

Aqui está uma citação de reproducible-builds.org :

Compilações reproduzíveis são um conjunto de práticas de desenvolvimento de software que criam um caminho verificável do código-fonte legível para o código binário usado pelos computadores.

Por que eles são importantes?

Na IMO, a maneira mais fácil de explicar sua importância é considerá-los como uma variação de um procedimento de backup.

Como um exemplo:

• Suponha que uma empresa que use (dependa) de algum pacote de software licenciado por algum fornecedor de software. Enquanto a empresa obtém apenas os executáveis, não as fontes, etc., que foram usadas para criar esses executáveis.

• Tudo corre bem, mas em algum momento algo dá errado com o fornecedor do software, por exemplo, eles saem do negócio (por exemplo, falência).

• Isso pode expor um risco para os negócios (a longo prazo). Ou seja, se não houver procedimento / acordo em vigor para que a empresa obtenha acesso (legal) a todas as fontes, documentação, procedimentos de compilação necessários, etc. relacionados a qualquer coisa do fornecedor de software usado (antigamente) quando os executáveis ​​(usados ​​por o negócio) foram criados (e enviados para o negócio).

• É aí que o " Software Escrow " vem em socorro: se houver tal acordo, alguém poderia pensar que, através de terceiros, ainda seria possível que a empresa tivesse acesso ao " tudo o que foi usado " para poder reproduzir os executáveis, para que, a partir de então, a empresa possa ter a chance de continuar usando esse software e, onde apropriado, começar a mantê-lo (por administrar apenas seus próprios negócios).

• No entanto, o " tudo o que foi usado " no item anterior é a parte mais difícil de fazer esse trabalho. Exige que terceiros executem validações apropriadas antecipadamente. E, acredite, leva um tempo até que você possa recriar um executável para o qual possa provar que, além da (por exemplo) data do link, é uma combinação perfeita com o que o fornecedor do software entrega ao agente de software.

E por que eles são tão difíceis de criar?

Se a amostra acima ainda não estiver clara o suficiente, imagine que você é meu agente de garantia de software, diga-me o que precisa como entrada para recriar uma cópia do software licenciado pelo meu cliente. Pegue? Você não esqueceu de verificar qual versão do meu compilador, talvez meu sistema operacional, opções de compilação / link, versões de componentes reutilizáveis ​​(inclui), bibliotecas, etc.?

Para fornecer um exemplo prático de uma tentativa de criar uma compilação verdadeiramente repetível, considere o seguinte:

Um pipeline de construção que começa com um repositório git para o qual nenhum usuário pode reescrever o histórico ou excluir ramificações não imersas.

A primeira etapa de "compilação" depois de verificar o código-fonte é girar um contêiner que contém todas as dependências de tempo de compilação.

A saída do contêiner em tempo de construção em execução é um contêiner que contém o binário compilado.

Mais importante para a repetibilidade da construção, as seguintes tags são adicionadas ao contêiner final:

• O hash exato do código-fonte no repositório original e a URL do repositório git e um instantâneo tar ball do código que é carregado em um repositório de artefatos.
• A versão exata do contêiner de construção que foi usado para executar a construção.
• A versão exata da imagem base original na qual o binário foi carregado.
• Os valores de todas as variáveis ​​de tempo de construção usadas para criar o binário.
• A versão da janela de encaixe na qual todos os três contêineres foram criados e a versão em que estavam sendo executados quando foram criados.

Ao adicionar todos esses metadados, podemos garantir que, em qualquer momento no futuro, possamos extrair o conjunto exato de dependências de compilação (via contêiner de compilação), compilar o binário com um conjunto exato de etapas conhecido (consagrado no contêiner de compilação ) e empacotá-lo em outra imagem base conhecida com todas as dependências em tempo de execução (usando a marca de imagem base) e tudo isso pode se basear na versão correta exata do código-fonte com base na marca no contêiner.

Teoricamente, isso deve nos dar a capacidade de reproduzir exatamente uma versão de compilação.

A importância disso é que ele nos permite analisar o que está em execução na produção e, mesmo que tudo tenha avançado significativamente, volte e retire a versão do código, imagem de base e construa o contêiner originalmente usado para que possamos, por exemplo , aplique um hotfix a essa versão antes de reconstruir exatamente como antes, para que possamos reimplementar sabendo que é exatamente o mesmo artefato, com o único delta sendo o hot fix.