São compilações diárias o caminho a percorrer para uma aplicação web?

Question

Joel parece pensar muito de compilações diárias . Para uma aplicação tradicional compilado posso certamente ver a sua justificação, mas como é que este paralelo sobre o desenvolvimento web - ou não é verdade

Um pouco sobre o projeto que eu estou pedindo - Existem 2 desenvolvedores trabalhando em uma aplicação web Django (Python). Nós temos 1 svn repositório. Cada desenvolvedor mantém uma saída e thier própria cópia do MySQL rodando localmente (se você não estiver familiarizado com Django, que vem com ele é servidor de teste próprio, da mesma forma aplicativos ASP pode ser executado dentro de Visual Studio). Desenvolvimento e teste é feito localmente, em seguida, voltar comprometido com o repositório. A cópia de trabalho real do site é um check-out SVN (eu sei sobre SVN exportação e leva muito tempo). O mais próximo que temos de uma 'construir' é um arquivo em lotes que executa uma atualização SVN na cópia de trabalho, faz os bits Django ( 'syncdb manage.py'), atualiza o cache motor de busca (Solr), em seguida, reinicia Apache.

Eu acho que o que eu não vejo é o paralelo para aplicações web.

Você está fazendo uma aplicação web controlado fonte com 'nightly builds' -? Se assim for, o que faz que se parecem com

Answer 1

Você pode facilmente executar todos os testes de unidade Django através do framework de testes Django como seu nightly build.

Isso é o que fazemos.

Temos também alguns testes de unidade comuns que não alavancar Django apresenta, e corremos aqueles, também.

Apesar de Python (e Django) não requerem o tipo de nightly teste de compilação / link / unidade que linguagens compiladas fazer, você ainda beneficiar da disciplina diária de "não quebrar a construir". E um ciclo diário de teste de unidade tudo que você possui é uma coisa boa.

Estamos no meio de olhar para Python 2.6 (que funciona perfeitamente para nós) e rodando nossos testes de unidade com a opção -3 para ver qual obsoleto recursos que estamos usando. Ter um conjunto completo de unidade testa assegura-nos que uma mudança para compatibilidade Python 3 não vai quebrar a construir. E executá-los meios noturnos que nós temos que ser certeza estamos refatoração corretamente.

Answer 2

A integração contínua é útil se você tem os processos corretos em torno dele. TeamCity da JetBrains é um excelente ponto de partida se você quiser construir familiaridade:

http://www.jetbrains.com/teamcity/index.html

Há um ótimo artigo que se relaciona diretamente com Django aqui:

http://www.ajaxline.com/continuous-integration-in -django-projeto

Espero que isso faz com que você começou.

Answer 3

Aplicativos da Web criados em linguagens dinâmicas não pode exigir um passo "compilação", mas ainda pode haver uma série de passos "construir" envolvidos na obtenção do aplicativo para executar. Seus scripts de construção pode instalar ou atualizar dependências, executar migrações de banco de dados, e depois executar o conjunto de testes para garantir que o código é w.r.t. "limpa" o real check-in versão no repositório. Ou, você pode implantar uma cópia do código para um servidor de teste, em seguida, executar um conjunto de testes de integração de selênio contra a nova versão para garantir que a funcionalidade do site do núcleo ainda funciona.

Ela pode ajudar a fazer algumas leituras sobre o tema da integração contínua, que é uma muito prática útil para as equipes webapp dev. Quanto mais rápido e ágil o processo de desenvolvimento, mais você precisa de entrada regular de testes e qualidade métricas automatizadas para se certificar de você falhar rápido e alto em qualquer versão quebrada do código.

Answer 4

Se ele é realmente apenas você e um outro desenvolvedor trabalhando nisso, nightly builds são provavelmente não vai dar-lhe muito.

Eu diria que o equivalente aplicativo web de sites de nightly builds seria estadiamento (que pode ser construído noturno).

Onde nightly builds a um começo área de teste pagar dividendos reais é quando você tem clientes, gerentes de projeto e pessoas QA que precisam ser capazes de ver uma atualizada, mas a versão relativamente estável do aplicativo. Suas caixas de areia para desenvolvedores (se você gosta de mim, pelo menos) provavelmente gastar muito tempo em um estado inutilizável como você está quebrando coisas tentando obter o próximo recurso implementado. Portanto, o problema típico é que uma pessoa QA quer verificar se um erro é corrigido, ou um PM quer verificar que alguma característica planejada foi implementado corretamente, ou um cliente quer ver que você fez progressos na questão que eles se preocupam sobre. Se eles só têm acesso às caixas de proteção para desenvolvedores, há uma boa chance de que quando chegar ao redor para olhar para ele, a versão sandbox não está em execução (uma vez que significa runserver ./manage.py é em um lugar terminal) ou é em um estado quebrado por causa de outra coisa. Isso realmente retarda toda a equipe e resíduos muito tempo.

Parece que você não tem uma configuração de ocorrência, desde que você acabou de atualizar automaticamente a versão de produção. Isso poderia ser bom se você está maneira mais cuidadoso e disciplinado do que eu (e eu acho que a maioria dos desenvolvedores) estou e nunca cometer qualquer coisa que não é totalmente à prova de balas. Pessoalmente, eu prefiro ter certeza de que meu trabalho tem feito isso por meio de pelo menos alguns QA superficial por alguém que não me antes que bata produção.

Assim, em conclusão, a configuração onde eu trabalho:

• cada desenvolvedor executa sua própria sandbox localmente (o mesmo que fazê-lo)
• há um "comum" sandbox de teste em um servidor dev que será actualizado todas as noites a partir de um cronjob. PMs, clientes e QA ir lá. Eles nunca têm acesso direto às caixas de proteção para desenvolvedores.
• Há uma (embora iniciada manualmente) implantação automatizada para a produção. Um desenvolvedor ou o PM pode "empurrar" para a produção quando sentimos as coisas têm sido suficientemente QA'd e são estável e seguro.

Eu diria que a única desvantagem (além de um pouco de ajuste sobrecarga extra-se a encenação nightly builds) é que faz para um dia de recuperação na verificação bug. ou seja, QA relata um bug no software (baseado em olhando para construir noturno daquele dia), desenvolvedor de correções de bugs e commits, então QA deve esperar até construção do dia seguinte para verificar se o bug é realmente fixo. Geralmente não é muito de um problema, já que toda a gente tem bastante material acontecendo que ele não afeta o cronograma. Quando um marco é aproximar embora e nós estamos em um, bugfix único modo de longa-congelado, vamos fazer atualizações manuais mais freqüentes do site de teste.

Answer 5

Eu tive grande sucesso usando Hudson para integração contínua. Detalhes sobre como usar Hudson com Python por Redsolo .

Há alguns meses, vários artigos Desposar implantação contínua causou uma grande celeuma online. IMVU tem detalhes sobre como eles implantar até 5 vezes por dia .

Answer 6

A idéia por trás frequente constrói (noturno ou mais frequente como em integração contínua) é obter feedback imediato, a fim de reduzir o tempo decorrido entre a introdução de um problema e sua detecção. Assim, a construção de freqüência só é útil se você é capaz de gerar algum feedback através da compilação, o teste (o ideal é automatizado), controlos de qualidade, etc. Sem feedback, não há nenhum ponto real.