야간 빌드를 중단했을 때 사과하는 방법 [닫기]

내 프로젝트에 대한 첫 번째 커밋은 야간 빌드가 깨졌으며 출시가 가까워지면서 사람들이 내 모든 곳입니다. 성실하게 들리면서 동시에 이것이 나의 첫 번째 커밋이며 더 이상 반복되지 않을 것이라는 암시를 표하는 사과 이메일을 보내려고합니다.

영어가 모국어가 아니기 때문에 올바른 단어를 찾기가 어렵습니다. 누군가 도와주세요?

사과 하지 마십시오 !

• 푸른 달에서 한 번 빌드를 깨는 것은 큰 문제가 아니며 절대로 쇼 스토퍼가되어서는 안됩니다.
• 지속적인 자동 빌드를 구성하지 않는 것은 관리자의 잘못입니다.

또한 귀하의 팀은 'Joel Test'에 실패하여 한 번에 빌드를 할 수 없습니다.

그렇다면 사과하지 말아야 할 또 다른 것이 될 것입니다. 실제로, 팀 반 패턴입니다.

베이글. 도넛. 기타 과거에 근무했던 한 회사에서 코드가 깨지거나 동료가 혼란을 일으키는 원인은 일반적으로 다음날 사과 식품을 가져옴으로써 해결됩니다.

우리는 어느 날 한 팀이 생산 데이터베이스를 날려 버렸고, 전체 팀에게 엄청난 공황과 늦은 밤을 일으켰습니다. 다음날 그는 햄버거를 점심으로 구웠다.

나는 동료 사과를 좋아합니다. 맛있고 맛있는 사과.

당신을위한 두 따옴표 :

실수하지 않는 사람은 대개 아무것도하지 않습니다 .-- William Connor Magee

실수하지 않는 사람은 충분히 노력하지 않습니다 .-- 웨스 로버츠

Jim G.에 동의합니다. 사과하지 말고 배우고 다시 실수하지 마십시오. DRY;)

사과하지 말고 가능한 한 빨리 IT를 수정하십시오. 그래도 모두가 적어도 한 번은 빌드를 중단합니다. 마지막 회사에서는 시작 의식이었습니다. 팀원이 빌드를 깨 뜨렸을 때 우리는 그가 오기 전에 아침에 책상에 고무 오리를 놓았을 것입니다.

우리는 그것을 Continuous Integration Duckie라고 불렀고 사람들이 당신을 놀리는 날을 보냈을 때 모두 재미있었습니다.

우리는 부서진 빌드와 같은 것을 가져다가 팀 빌딩 연습으로 바 꾸었습니다.

"미안해 내 잘못이다!" 빌드를 깨 뜨렸을 때 일반적으로 사과하는 방법입니다. 일어난다. 그러나 다른 사람들이 말했듯이 이것은 한 사람이 다른 사람의 빌드를 쉽게 깨뜨리지 못하도록 시스템을 개선 할 수있는 기회입니다.

나는 이런 상황에서 공식적인 사과를하지 않을 것이지만, 실제로 더 공식적인 사과가 적절하다고 생각한다면, 당신의 사과는 다음과 같이해야합니다 :

• 후회를 표현하십시오.
• 문제를 언급하다.
• 책임감을 가지다.
• 수정하십시오.
• 얼굴 보존.

즉, "실수로 [저장 공간]을 구축하여 [문제를 해결]하여 [책임감]에 불편을 드려 죄송합니다. [EXPRESS REGRET]. 도넛은 내일 있습니다.

각 부분은 적절한 사과에 필요합니다. 문제를 언급하지 않으면 명확하지 않습니다. 후회를 표현하지 않고 책임을지고 수정하면 사람들은 당신이 진실하지 않은 것처럼 느낍니다. 얼굴 절약 부분은 사과에서 가장 간과되는 부분입니다. 얼굴을 아끼는 부분은 부상당한 당사자에게 당신이 때때로 실수를하는 귀중한 동료임을 상기시키는 것입니다.

마지막으로, 빌드 브레이킹에 대한 몇 가지 생각 :

C # / Visual Basic 컴파일러 팀에서 일하고 있습니다. 물론 오늘날 Visual Studio는 이제 빌드 인프라를 관리하기위한 자체 팀과 자체 전용 에어컨 시스템이있는 방이 큰 프로젝트입니다. 1990 년대 중반 제가 인턴으로 시작했을 때 Visual Basic 빌드 팀은 하나의 인턴이었고 나에게는 많은 기계가있었습니다. 시대가 바뀌었다!

그 당시에는 지속적인 통합과 강력한 체크인 프로세스가 이루어지기 전에 팀이 빌드를 어길 때 다양한 처벌을 받게되었습니다. 일부 팀의 경우 벌칙은 빌드를 중단 한 경우 다른 사람이 빌드를 중단 할 때까지 매일 직장에서 재미있는 모자를 착용해야한다는 것이 었습니다. 일부 팀에서는 모자를 쓰고 있다면 야간 빌드가 올바른지 확인해야합니다.

마지막 비트 소리는 잔인하지만 실제로는 귀중한 목적을 달성했습니다. 거의 모든 사람이 한 번에 한 번씩 빌드를 중단 했으므로 결국 전체 팀이 야간 빌드를 확인하는 프로세스를 알게됩니다.

사과하지 마십시오. 첫 번째 커밋을 검토하지 않고 지속적인 통합 서버와 같은 빌드에 대한 빠른 피드백 시스템을 가지고 있지 않은 것은 비난을받는 동료입니다.

현재 직장에서는 직장을 떠나기 직전에 몰래 커밋하고 빌드를 중단하는 사람이 다음날 전체 팀을 위해 사탕 / 케이크 / 음료를 가져와야한다는 비공식 규칙이 있습니다. 그러나 우리는 하루 동안 깨진 빌드를 경고하는 지속적인 통합을 가지고 있습니다. 그리고 규칙은 아마도 누군가의 첫 번째 커밋에는 적용되지 않을 것입니다.

어쨌든, 공식적인 사과 메일은 아마도 너무 많을 것입니다.

기본 규칙-당신이 틀렸을 때, 그것을 인정하십시오 :-| 사과 할 필요가 없습니다. 누구나 실수를합니다. 전문가들이 인정합니다. 팀워크입니다. 다른 팀원들이 당신을 도와 줄 수 있도록 함께 모여야합니다. 그렇지 않은 경우 도움을 요청하십시오. 나중에 말해야 할 가장 큰 것은 우리가 무엇을 배울 수 있습니까?

그들은 성공적인 결혼이 세 가지 작은 단어에 근거한다고 말합니다.

누군가 실수로 실수하지 않으면 작동하지 않지만 배우지 못하는 실수는 두 가지 실수입니다.

최고의 사과는 휴식 시간을 빠르게 고치는 것입니다

회사에 이미 빌드 변경 사항을 테스트 할 수있는 방법이 있다면 (A) 변경 사항이 실패했지만 (어쨌든 확인 했음) 또는 (B) 성공 했으므로 (새로운 테스트 사례를 작성해야 함).

동료가 변경 사항을 진지하게 테스트하고 야간 빌드에서 중단을 기대하는 경우 (C) 취성 프로세스가 있으며 극단적 인 프로그래밍에서와 같은 테스트를 도입해야합니다.

(D) 귀하의 변경으로 인해 귀하와 동일한 빌드에서 변경되었거나 청구서 코드가 예기치 않게 변경되었을 수 있습니다.

귀하와 귀사의 테스트 방법에 따라 사례별로 사과드립니다.

• (A) 빌드 테스트에 실패했지만 변경 사항을 확인했습니다. 죄송합니다. 프로세스를 변경하여 다시는하지 않습니다.
• (B) 빌드 테스트를 통과하고 재발생 가능성을 줄이기 위해 JUnit 테스트 XYZtest.java를 추가했습니다.
• (C) 빌드 테스트 프로세스가 없기 때문에 변경 사항을위한 프로세스를 만들고 있습니다. 빌드 프로세스를 개선 할 수있는 방법을 알려 드리겠습니다.
• (D) Bill과 협력하여 재발생 가능성을 줄이기 위해 JUnit 테스트 XYZtest.java를 작성합니다.

내가 생각하지 못한 (E)가 있다고 확신합니다.

"다시 발생하지 않을 것"보다는 "재발생 가능성을 줄이겠다"고 말하고 있습니다. 다시 일어날 것이다. 그러나 그 가능성을 줄이기 위해 프로세스를 개선 할 수 있습니다. 내 생각에는이기는 프로그래머의 표식 중 하나입니다.

사과하지 마십시오. 당신은 인간이며 실수를 할 것입니다. 누구나 빌드를 가끔씩 중단 할 수 있습니다. 열쇠는 단지 빨리 수정하는 것입니다.

사람들이 당신을 뛰어 넘는 것에 관해서는 ... 글쎄 그들은 그들이 버그로 쓴 적이 있는지 궁금합니다.

접근 방법은 그룹의 분위기에 따라 다릅니다. 그것이 비난의 문화라면, 나는 사과하고 당신이 그것을하는 방법에 매우 주의를 기울입니다. 그것이 협력적이고 긍정적 인 분위기라면, 그래요. "엉망이되어서 죄송합니다. 앞으로 어떻게 피할 수 있을까요?" 아마 좋은 생각 일 것입니다.

어쨌든, 이와 같은 구식에는 a) 어떻게 일어 났는지 알아 내고 b) 다시 일어날 가능성을 최소화하는 방법에 대한 사후 부류가 수반되어야한다.

나는 당신의 구조에 익숙하지 않습니다 (나는 매우 다른 환경에서 일합니다). 그러나 궁극적으로 현실은 때때로 사람들이 실수를하고 일이 부서진다는 것입니다. 당신은 경험에서 배우고 계속합니다.

내 환경에서 당신이 빌드를 깨뜨렸다면 당신은 좋은 성격의 늑골과 재치있는 혜성을 얻을 것입니다. 어느 영어권 국가인지 확실하지 않지만 영어를 모국어로 사용하지 않는 사람은 주석의 밑줄을 그리지 않을 수 있습니다.

선임 개발자로서 다른 쪽에서 나는 코드 검토에 대해 한 번 언급했다. 코드를 잘못한 것이 아니라 프로젝트의 구조에 영향을 미쳤 기 때문에 x를 수행하는 방법이 "빨리 빠졌다". 구조적 문제를 해결해야한다는 의견이 더 많았습니다. 나중에 나는 정확하지 않은 플립 팬트 연설 때문에 그에게 매우 화가 났지만 Jr Dev를 발견했습니다.

음 깨진 빌드 토큰을 얻습니다 . 다음 운이 좋은 수령인에게 광견병을 전달하십시오. 항상 일어난다. 품질은 중요하지만 실수는 불가피합니다. 그것들을 수정하십시오. 어서 다음 불쌍한 녀석을 부끄러워하십시오.

일반적으로 다음과 같이 말합니다.

체크인시 컴파일러 오류가 발생하는 경우 체크인하기 전에 "최신 정보 얻기"를 수행 한 경우 간단한 "누가, 내 나쁜 상태"인지 확인하십시오. (특히 다음날 아침 10시에 산책하는 경우 모든 사람이 롤백 할 변경 세트를 결정하는 동안)

체크인이 일반적인 예기치 않은 동작, 심지어 런타임 오류를 유발하는 경우에는 이것이 귀하에게 불리한 것으로 생각되지 않습니다. 영토와 함께 제공됩니다. 모든 사람의 "최신 정보"가 일반적으로 컴파일러에 전달되는 한, 사람들은 실제로 데이터베이스를 삭제하거나 프로젝트의 서버 사본 및 모든 변경 세트를 삭제하는 등의 예외를 제외하고 는 적합하지 않아야합니다. 사람들이 악의적 인 의도를 취해야한다는 바보 같은 말).

TEAM이 실패했습니다.

회사는 처음 빌드를 수행하는 개발자에 대해 더 많은 코드 검토가 필요합니다.

나는 팀이 검토를 수행하지 않고 어떻게 작업을 올바르게 수행하는지에 대한 확신을 제공하지 않고 어떻게 진행할 수 있는지 알지 못합니다.

출시 시간이 가까워 졌다는 것은 변명이 아니라 새로운 코드를 다시 확인해야하는 더 좋은 이유입니다.

릴리스를 쉽게 취소 할 수없는 경우이 그룹에 더 큰 문제가 있습니다.

왜 사람들이 당신을 온통 이해하지 못합니다. 시스템이 제대로 설정되면 변경 사항을 해결할 수 있고 매우 신속하게 수정할 수 있습니다.

그러나 다시, 만약 당신이 창문을 깨뜨린 사람들 중 하나라면 ... 나는 도울 수 없습니다. (누군가 MS가 철학을 세우는 것에 의문을 제기하기 전에, 그러나 누군가가 그렇게하기 전에 회사 전체의 QA가 하루 동안 중단됩니다.)

그리고 그렇습니다-사과하지 마십시오. 관리자와 대화를 나누고 자신이 한 일을 통해 배운 사실을 이해하게하십시오.

빌드는 항상 끊어집니다. 버그와 실수는 인생의 사실이므로 버그와 실수의 영향을 최소화하는 프로세스를 갖추어야합니다.

빌드 브레이킹이 큰 문제라면 프로세스가 손상되었다는 의미입니다.

야간 빌드가 아닌 연속 빌드를 수행해야합니다.

결코 대답보다 늦게 대답하는 것이 좋습니다 ...

다른 많은 사람들이 말했듯이 빌드를 중단 한 것에 대해 사과하지 마십시오. 그것이 당신이라는 것을 인정하고 일을 시작하십시오. 이 물건은 당신이 거기 있든 없든 일어날 것이고, 아무도 그로 인해 제대로 대우받을 자격이 없습니다. 사람들은 압박을 받고 심하게 반응하므로 침착하게 일을 계속할 수 있다면 중요한 순간에 눈에 띄게됩니다. 사람들이 어려움을 겪을 때의 조언은 단순히 방어적인 태도를 피하고, 문제를 겪고 있다는 사실을 사람들에게 알리거나 상황에 처하게되면 신속하게 조언을 구하는 것입니다.

개인적으로, 나는 깨진 빌드를 기회로 본다.

• 빌드가 중단되고 결함이 있음을 증명할 수 있으면 지속적인 통합 및 빌드 프로세스가 작업을 수행하고 있음을 보여줄 수 있습니다. 프로세스의 유효성을 검사하는 것이 좋습니다. 빌드가 중단되지 않으면 문제가있는 것 같습니다.
• 상당히 일반적인 방식으로 빌드를 깨뜨 렸고 이런 방식으로 자주 깨지는 경우 CI 프로세스에서 무언가가 누락되었을 수 있습니다. 이는 일반적인 장애 시나리오를보다 잘 관리 할 수 ​​있도록 프로세스를 개선 할 수있는 기회입니다.
• 직무를 넘어서서 모호한 문제로 빌드를 엉망으로 만들었다면 팀의 다른 팀에게 경고를 유발할만큼 중요한 새로운 것을 배울 기회가 있습니다.

제가 말하는 것은 때때로 빌드를 깨는 것은 사람들이 일을하고 있다는 것을 의미합니다. 물론 실수를했을 수도 있지만, 배우는 기회로 사용한다면 다음 번에 더 잘 배우는 것만으로도 일을하는 것입니다.

체크인 당 CI 빌드가 필요하다고 알려주십시오. 그렇게하면 밤이 될 때까지 기다릴 필요가 없습니다. 네!!! 그들에게 잘못된 과정이라고 말하십시오. 당신은 그들의 시스템 에서 차이를 식별했습니다 .

그러나 그렇습니다, 고쳐야합니다. 별거 아니야 생산 중이 아닙니다. 그냥 쓸모없는 밤입니다.

우리 회사의 일반적인 관행은 다음과 같습니다.

• "나 아니 었어!" (보통 CVS / SVN 증명)
• "my-userlogin ist Schuld!"라는 티셔츠를 입고 (예, 개발자 자신의 셔츠의 50 %)
• 로컬 sendbox에서 작동한다고 주장하고 모든 테스트는 정상적으로 통과했습니다.

우리 회사는 또한 이러한 "사고"를 처리하는 좋은 방법이 있습니다

• 근로자는 반나절 동안 다음 의상을 입어야합니다 ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• 사과하지 않겠습니다.

• 깨진 빌드를 저지른 CI 리드를 비난합니다.

• 개발자가 깨진 코드를 커밋하지 못하게하려면 CI 프로세스가 있어야합니다.

• 로컬 빌드가 실패하면 빌드 서버에 들어가서는 안됩니다.

어떤 종류의 사과가있을 수 있다고 생각하지만 "이런 일이 다시는 일어나지 않도록 할 것입니다."라고 말하지 마십시오. 그렇기 때문에. 그리고 그것이 당신을 물 것입니다.

오픈 소스 프로젝트를 진행중인 경우

그냥 "죄송합니다. 빌드를 망쳤습니다. 너무 졸려서 일 수 있습니다!"

그것을 github 주석으로 추가하십시오.

많은 오픈 소스 개발자가 자정 중에 코드를 작성하기 때문입니다.