Como pedir desculpas quando você interrompeu a compilação noturna [fechado]

Meu primeiro commit no meu projeto resultou na construção noturna sendo interrompida e as pessoas estão em cima de mim quando estamos chegando ao lançamento. Quero enviar um e-mail de desculpas que deve parecer sincero e ao mesmo tempo sugerir que esse foi meu primeiro commit e que isso não seria mais repetido.

Sendo um falante de inglês não nativo, tenho dificuldades em encontrar as palavras corretas. Alguém pode ajudar por favor?

Não peça desculpas!

• Quebrar a construção uma vez na lua azul não é grande coisa e nunca deve ser um obstáculo para o show.
• A culpa é do seu gerente por não configurar versões contínuas e automatizadas.

Além disso, aposto que sua equipe falhou no 'Teste Joel' e não pode fazer uma compilação em uma única etapa.

Nesse caso, isso seria outra coisa pela qual você não deveria se desculpar. Na verdade, é um anti-padrão de equipe.

Bagels. Donuts. Etc. Em uma empresa em que trabalhei no passado, o check-in de código quebrado ou a interrupção de colegas é geralmente resolvido com a introdução de pedidos de desculpas no dia seguinte.

Tivemos um cara que explodiu um banco de dados de produção um dia, causando pânico e muita madrugada para toda a equipe. No dia seguinte, ele grelhava hambúrgueres no almoço.

Eu amo desculpas de colegas de trabalho. Saborosas, desculpas saborosas.

Duas citações para você:

O homem que não comete erros geralmente não faz nada. - William Connor Magee

Quem não cometer erros não está se esforçando o suficiente. - Wess Roberts

Concordo com Jim G. , não me desculpe, mas aprenda com ele e não cometa o mesmo erro novamente ... mantenha-o SECO;)

Não se desculpe, basta corrigi-lo o mais rápido possível. Tudo bem, no entanto, todo mundo quebra a construção pelo menos uma vez, na minha última empresa, foi como um ritual de iniciação. Quando um membro da equipe quebrava a compilação, colocávamos um patinho de borracha em sua mesa na manhã anterior à sua entrada, para que ele soubesse que ele quebrou a compilação e ele a consertaria.

Nós o chamamos de Duckie de Integração Contínua e, quando você o tinha durante o dia, as pessoas o provocavam, mas tudo era divertido, nada disso deveria ser mesquinho.

Pegamos algo como uma construção quebrada e a transformamos em um exercício de construção de equipe.

"Desculpe, minha culpa!" é assim que geralmente peço desculpas quando quebrei a compilação. Acontece. Mas, como outros já disseram, esta é uma oportunidade para melhorar seus sistemas, para que uma pessoa não possa quebrar com facilidade a construção para todos os outros.

Eu não faria um pedido formal de desculpas nessas circunstâncias, mas se você realmente acha que um pedido de desculpas mais formal é apropriado, seu pedido de desculpas deve fazer o seguinte:

• Expressar arrependimento.
• Indique o problema.
• Tomar responsabilidade.
• Faça as pazes.
• Salve o rosto.

Ou seja, "Sinto muito [EXPRESSAR Lamentar] por ter incomodado você [TOMAR RESPONSABILIDADE] por acidentalmente [SALVAR CARA] violando a construção [DECLARAR O PROBLEMA]. Os donuts estão comigo amanhã. [FAÇA AMENDS]" "

Cada parte é necessária em um pedido de desculpas apropriado; se você não indicar o problema, não está claro. Se você não se arrepende, assume a responsabilidade e faz as pazes, as pessoas se sentem insinceras. A parte de salvar o rosto é a parte mais esquecida de um pedido de desculpas; a parte de salvar o rosto é o que lembra à pessoa ferida que você é um colega valioso que às vezes comete erros, e não um idiota (ou um sabotador!)

Finalmente, algumas reflexões sobre a quebra de build:

Trabalho na equipe do compilador C # / Visual Basic. É claro que hoje o Visual Studio agora é um projeto tão grande que possui uma equipe própria apenas para gerenciar a infraestrutura de construção e uma sala enorme com seu próprio sistema de ar condicionado dedicado. Em meados dos anos 90, quando comecei como estagiário, a equipe de criação do Visual Basic era uma estagiária - eu - e um armário cheio de máquinas. Os tempos mudaram!

Naqueles dias antes da integração contínua e de processos sólidos de check-in, as equipes tinham uma variedade de penalidades por interromper a construção. Em algumas equipes, a penalidade era que, se você quebrasse a construção, teria que usar um chapéu engraçado todos os dias no trabalho até que outra pessoa quebrasse a construção. Em algumas equipes, se você usava esse chapéu, era responsável por verificar se a construção noturna estava correta.

Essa última parte parece talvez cruel, mas na verdade serviu a um propósito valioso. Como quase todo mundo quebrou a compilação de uma vez ou outra, eventualmente a equipe inteira aprendeu os processos para verificar a compilação noturna.

Não peça desculpas. Seus colegas de trabalho são os responsáveis ​​por não revisar seu primeiro commit e por não terem um sistema de feedback rápido para compilações como um servidor de integração contínua.

No meu trabalho atual, temos uma regra informal de que alguém que se comprometa furtivamente pouco antes de sair do trabalho e acaba quebrando a construção precisa trazer doces / bolos / bebidas para toda a equipe no dia seguinte. Mas temos uma integração contínua que nos avisa sobre uma construção quebrada durante o dia. E a regra provavelmente não se aplicaria ao primeiro commit de alguém.

De qualquer forma, um e-mail formal de desculpas é provavelmente um pouco demais.

Uma regra fundamental - quando você estiver errado, ADMITA: - | Você não precisa se desculpar. Todo mundo comete erros. Os profissionais admitem isso. Isso é trabalho em equipe. Os outros membros da equipe devem se reunir para ajudá-lo. Caso contrário, peça ajuda. O máximo que se pode dizer depois é: o que podemos aprender com isso?

Eles dizem que um casamento bem-sucedido se baseia em três pequenas palavras - "eu estava errado".

Se alguém não comete um erro ocasional, não está funcionando, mas um erro que não se aprende é o de dois erros.

O melhor pedido de desculpas é consertar o intervalo rapidamente

Se sua empresa já tem uma maneira de testar suas alterações de compilação, (A) suas alterações falharam (mas você as registrou mesmo assim) ou (B) elas foram bem-sucedidas (e você precisa criar um novo caso de teste).

Se seus colegas testam cuidadosamente suas alterações e esperam encontrar pausas na construção noturna, (C) você tem um processo frágil (e precisa introduzir testes como os encontrados na Programação Extrema).

É possível que (D) Suas alterações tenham causado alterações imprevistas no código de Bill, que estavam em vigor antes ou foram alteradas na mesma compilação que a sua.

Dependendo de como você e sua empresa testam, peço desculpas caso a caso:

• (A) Falha no teste de construção, mas verifiquei minhas alterações. Desculpe, estou alterando meu processo para não fazer novamente.
• (B) Passei no teste de construção e adicionei o teste JUnit XYZtest.java para reduzir a chance de nova ocorrência.
• (C) Como não temos um processo de teste de construção, estou criando um para minhas alterações. Gostaria de compartilhar com você como podemos melhorar nosso processo de criação.
• (D) Trabalharei com Bill para escrever um teste JUnit XYZtest.java para reduzir a chance de ocorrência.

Tenho certeza de que há um (E) em que não pensei.

Observe que estou dizendo "reduzir a chance de reincidência" em vez de "para que isso não aconteça novamente". Isso vai acontecer novamente. Mas você pode melhorar seu processo para reduzir essa possibilidade. Acho que essa é uma das marcas de um programador vencedor.

Não peça desculpas. Você é humano e cometerá erros. Todo mundo irá quebrar a compilação ocasionalmente, a chave é corrigi-la rapidamente.

Quanto às pessoas pulando em cima de você ... bem, estou curioso para saber se elas já escreveram um bug.

Como abordar isso depende da atmosfera do seu grupo. Se é uma cultura de culpa, eu teria muito cuidado em pedir desculpas e como você faz isso. Se é uma atmosfera positiva e colaborativa, sim, algo como "Eu errei, me desculpe. Como podemos evitar isso no futuro?" provavelmente é uma boa ideia.

De qualquer forma, uma brincadeira como essa deve ser acompanhada de algum tipo de post-mortem para: a) descobrir como isso aconteceu eb) como minimizar as chances de isso acontecer novamente.

Não estou familiarizado com a sua estrutura (trabalho em um ambiente muito diferente), mas, em última análise, a realidade é que, ocasionalmente, as pessoas cometem erros e as coisas quebram. Você aprende com a experiência e segue em frente.

No meu ambiente, se você quebrasse a construção, obteria uma boa nervura e um cometa espirituoso. Não sei em que país de língua inglesa você está, mas pode ser que, como um falante não nativo, você não esteja recebendo a natureza sublinhada dos comentários.

Sendo do outro lado como desenvolvedor sênior, certa vez, comentei em uma revisão de código que alguma maneira de fazer x "era ruim" não porque o código era ruim, mas afetava a estrutura do projeto. Foi mais um comentário para mim mesmo que eu precisava resolver o problema estrutural. Só mais tarde descobri que o Jr Dev estava muito zangado com ele devido ao meu discurso impreciso e irreverente.

Hum. Você recebe o token de compilação quebrado . Passe a raiva para o próximo sortudo. Acontece o tempo todo. A qualidade é importante, mas os erros são inevitáveis. Consertá-los. Ir em frente. Vergonha o próximo pobre cara.

Como regra geral, eu diria:

Se o seu check-in causar um erro do compilador, você se surpreenderia se tivesse feito uma "atualização mais recente" antes de fazer o check-in, um simples "grito, meu mal" está em ordem. (especialmente se você passear às 10 da manhã seguinte, enquanto todo mundo estiver decidindo para qual mudança mudar)

Se o seu check-in causar um comportamento inesperado geral, até mesmo erros de tempo de execução, não acho que deva ser mantido contra você. Vem com o território. Desde que todos os usuários "recebam as últimas atualizações" geralmente sejam aprovados em seus compiladores, as pessoas realmente não devem estar se adaptando (com algumas exceções, como excluir um banco de dados, excluir a cópia do servidor do projeto e todos os conjuntos de alterações ou qualquer outra coisa que seja tão burro que as pessoas têm que assumir intenções maliciosas).

A equipe falhou.

Sua empresa precisa de mais revisão de código em um desenvolvedor fazendo uma primeira compilação.

Só não vejo como uma equipe permite que isso continue sem que eles façam uma revisão e ofereçam algumas garantias ao longo do caminho de que você está fazendo as coisas corretamente.

Estar perto do tempo de lançamento não é uma desculpa, mas uma razão melhor para verificar novamente o novo código.

Se sua liberação não puder ser facilmente desfeita, há problemas ainda maiores com esse grupo.

Eu não entendo por que as pessoas estão em cima de você. Se o sistema estiver bem configurado, eles deverão conseguir alterar suas alterações / corrigi-las rapidamente.

Mas, novamente, se você é um daqueles caras que quebraram as janelas, então ... eu não posso ajudar. (É incrivelmente difícil fazer o que se pede - antes que alguém questione a EM construindo filosofias, mas de vez em quando alguém o faz - e todo o controle de qualidade da empresa pára por um dia).

E sim - não se desculpe. Converse com seu gerente e faça-o entender que você aprendeu com o que fez.

Construções quebram o tempo todo. Erros e erros são um fato da vida, e é por isso que você deve ter um processo que minimize os efeitos de erros e erros.

Se uma quebra de construção é um problema, significa que seu processo está quebrado.

Você deve fazer construções contínuas, não noturnas.

Melhor uma resposta tardia do que nunca ...

Como muitos outros disseram, não peça desculpas por quebrar a compilação. Simplesmente admita que era você e continue com o trabalho. Isso aconteceria se você estivesse lá ou não, e ninguém merece ser tratado mal por causa disso. As pessoas reagem mal sob pressão; portanto, se você conseguir manter a calma e simplesmente continuar o trabalho, você se destacará quando for importante. Meu conselho para quando as pessoas enfrentam dificuldades é simplesmente evitar ficar na defensiva, desarmar a situação, informando as pessoas de que você está ou não envolvido no problema ou você é rápido em procurar conselhos se descobrir que ficou preso.

Pessoalmente, vejo uma construção quebrada como uma oportunidade.

• Se a construção for interrompida e você puder provar que é sua culpa, é provável que mostre que os processos de integração e construção contínuos estão fazendo seu trabalho. Isso é bom, pois valida seus processos. Se a construção nunca quebrar, eu me preocuparia que houvesse algo errado com ela.
• Se você quebrou a compilação de uma maneira bastante comum e acontece com frequência dessa maneira, talvez algo esteja faltando no processo do IC. Esta é uma oportunidade para melhorar seus processos para que os cenários de falha comuns possam ser melhor gerenciados.
• Se você foi além do dever e realmente atrapalhou a construção com um problema obscuro, terá a oportunidade de aprender sobre algo novo que pode ser importante o suficiente para acionar um aviso ao resto da equipe.

Então, o que estou dizendo é que quebrar a compilação ocasionalmente significa que as pessoas estão fazendo seu trabalho. Claro que você pode ter cometido um erro, mas se você usá-lo como uma oportunidade de aprender, estará fazendo seu trabalho simplesmente aprendendo a fazê-lo melhor da próxima vez.

Diga a eles que precisam de compilações de IC por check-in. Dessa forma, você não precisaria esperar até a noite para saber que está quebrado. SIM!!! Diga a eles que é o processo que está errado, nada mais. Você acabou de identificar uma lacuna no sistema deles .

Mas sim, certifique-se de consertar. Não é grande coisa. Não está em produção. Apenas uma noite inútil.

Uma prática usual na minha empresa é:

• Gritando "não fui eu!" (geralmente provas CVS / SVN de outra forma)
• Vestindo uma camiseta dizendo "my-userlogin ist Schuld!" (sim, 50% da camisa do nosso desenvolvedor)
• Alegando que funciona na caixa de envio local e que todos os testes foram aprovados

Minha empresa também tem uma ótima maneira de lidar com esse "incidente":

• O trabalhador tem que usar a roupa a seguir por meio dia ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• Eu não pediria desculpas.

• Eu culparia o líder de IC por me permitir cometer uma construção quebrada.

• Deve haver um processo de IC para impedir que os desenvolvedores cometam códigos quebrados.

• Se a construção local falhar, não deverá ser permitido entrar no servidor de construção.

Embora eu ache que possa haver algum pedido de desculpas, não diga: "Vou garantir que isso não aconteça novamente". Porque vai. E se isso acontecer, ele vai te morder.

Se você estiver trabalhando em um projeto de código aberto,

apenas diga "Desculpe, eu quebrei a construção. Pode ser que eu estivesse com muito sono!"

e adicione-o como um comentário no github.

Isso ocorre porque muitos desenvolvedores de código aberto escrevem código durante a meia-noite.