Em 1935, o físico austríaco Erwin Schrödinger propôs um experimento mental no qual um gato é confinado em uma caixa de papelão com um vidro de veneno e um gatilho aleatório que pode liberar este veneno. O X da questão é que, enquanto um observador não avaliar o conteúdo da caixa, não podemos considerar que o gato esteja vivo ou morto. Então, segundo Schrödinger, devemos considerá-lo vivo e morto. Além dos inúmeros desdobramentos relacionados à física e como seus experimentos e resultados devem ser avaliados, este paradoxo traz para o resto de nós a importância do observador para a definição do estado do que é avaliado.
Na engenharia de software a construção de um projeto é iniciada com a integração de cada entrega dos desenvolvedores ao resto do projeto. À cada interação do processo de desenvolvimento, que gera novas entregas dos desenvolvedores, são realizadas novas integrações. Integrações podem simplesmente combinar as entregas mas também podem compreender avaliações de validade, qualidade, segurança, etc.
Embora realizar o processo de integração de forma contínua (ininterrupta) tenha sido proposto no início dos anos 90, apenas no fim daquela mesma década movimentos que procuravam dar mais agilidade ao processo de desenvolvimento de software propuseram que quanto mais contínua, a cada menor entrega, melhor seria para o processo de desenvolvimento de software. Este método ficou conhecido como integração contínua, ou em inglês Continuous Integration (ou simplesmente CI).
Para tornar este método viável é necessária a automação do processo de integração. E é evidente que quanto mais profundamente automatizada, melhor. Também fica evidente que quanto mais análises e validações forem realizadas melhor será a qualidade do produto.
Assim como não podemos afirmar que o gato de Schrödinger está vivo ou morto até abrirmos a caixa não sabemos se as entregas realizadas pelos desenvolvedores funcionam e atendem os requisitos de qualidade e segurança até realizarmos a integração das mesmas.
Em engenharia é comum ouvirmos a expressão “segurança por obscuridade”, onde algo é indevidamente considerado seguro por ter suas falhas escondidas ou não avaliadas. Este conceito também pode ser estendido à qualidade do projeto. Algo como desenvolver e proteger seu projeto na caixa de Schrödinger, uma dúvida que não queremos, certo?
