동료가 자신의 PC에서 테스트 할 필요가 없다고 생각하면 변경하고 커밋 한 다음 푸시합니다. 그런 다음 프로덕션 서버에서 테스트하여 실수를 한 것을 알게됩니다. 일주일에 한 번 발생합니다. 이제 그가 3 분 동안 커밋을하고 5 분 안에 프로덕션 서버에 배포하는 것을 보았습니다.

나는 이것이 좋은 일을하는 방법이 아니라고 몇 번 말했다. 나는 그에게 다시 무례하고 싶지 않아 그는 회사에서 나와 같은 상태에 있고 그는 나보다 더 일했다.

이 행동을 어떤 식 으로든 처벌하거나 가능한 한 불쾌하게 만들고 싶습니다.

시작하기 전에 회사는 FTP와 같은 골동품 방법을 사용하여 배포했으며 버전 관리가 없었습니다.

나는 Git, Bitbucket, Dploy.io 및 HipChat을 사용하도록 강요했습니다. 배포는 자동이 아니므로 누군가 dply.io에 로그인 한 후 배포 버튼을 눌러야합니다.

이제 프로덕션 서버에서 테스트하지 않도록하려면 어떻게해야합니까? HipChat 봇과 같은 것은 같은 줄에 반복적 인 편집이 있음을 감지하고 프로그래머에게 통지를 보낼 수 있습니다.

적절한 품질 보증 (QA) 프로세스가 필요합니다.

전문 소프트웨어 개발 팀에서는 개발 권한을 프로덕션으로 푸시하지 않습니다. 개발, 스테이징 및 프로덕션이라는 세 가지 이상의 별도 환경이 있습니다.

개발 환경에서 무언가 효과가 있다고 생각되면 먼저 QA 팀이 각 커밋을 테스트하는 스테이징을 진행하고 테스트가 성공한 경우에만 프로덕션으로 푸시됩니다. 이상적으로, 개발, 테스트 및 생산 추진은 별도의 사람들이 수행합니다. 개발자가 개발에서 스테이징까지만 배포 할 수있는 방식으로 QA 팀이 스테이징에서 프로덕션으로 만 배포 할 수있는 방식으로 빌드 자동화 시스템을 구성하면이를 보장 할 수 있습니다.

QA를 수행 할 사람을 고용하도록 경영진을 설득 할 수없는 경우 다른 사람의 역할을 수행 할 수 있습니다. 나는 diploy.io로 일한 적이 없지만 일부 빌드 자동화 시스템은 사용자가 개발에서 스테이징 및 스테이징에서 프로덕션으로 배포 할 수 있지만 동일한 빌드에 대해 두 가지를 모두 수행 할 수 없도록 구성 할 수 있습니다. 필수입니다 (그러나 귀하 중 한 명이없는 시간에 백업 인력이 있는지 확인하십시오).

또 다른 옵션은 지원 담당자가 QA를 수행하도록하는 것입니다. 이것은 추가 작업처럼 보일 수도 있지만 장기적으로 일부 작업을 안전하게 할 수있는 응용 프로그램의 변경 사항을 알고 있어야합니다.

아마도 개발 서버와 스테이징 환경을 원할 것입니다. 자신의 개인 웹 사이트를 제외하고는 로컬에서 프로덕션으로 밀려서는 안됩니다. 배포 프로세스는 dev-> staging-> prod 만 지원해야합니다. 조직에 따라 프로젝트 리드, 전담 QA 또는 매주 회전하는 의무가 될 수 있습니다. 푸시). 그러나 먼저 팀과 논의하여 바이 인을 받으십시오 (아래 참조).

이 행동을 어떤 식 으로든 처벌하거나 가능한 한 불쾌하게 만들고 싶습니다.

테스트 스위트를 가질 수 있습니다 (당신은 그 중 하나를 가지고 있습니까?) 프로덕션 서버에 있는지 여부를 결정하고 확인하는 경우 사무실의 모든 사람에게 전자 메일을 보냅니다 Looks like $username is testing on prod, watch out. 아마도 동료를 공개적으로 부끄럽게 만드는 것은 불쾌 할 것입니다. 또는 팀이 prod를 보지 못하게하는 IP 금지와 같은 기술적 제한을 만들 수 있습니다 (승인 할 수는 있지만 정당화해야 함).

그러나 권장하지는 않지만 문제를 겪고있는 사람이 아닌 문제처럼 보일 것이며 관심이없는 팀의 사람들에게 자신이 인기를 얻지 못할 수 있습니다.

확실히 당신이 정말로 원하는 것은이 행동이 처벌되는 것이 아니라 멈추는 것입니다 .

나는 그들에게 / us를 사용하도록 강요했다 ...]

워크 플로 개선을 옹호하는 것이 좋지만 동료를 많이 생각하지 않거나 완전히 지원하지 않는 것처럼 들립니다. 이로 인해 동료들은 워크 플로와 반열 적으로 상호 작용하여 코드를 프로덕션에 가져 오는 데 필요한 최소한의 작업 만 수행 할 수 있으며 실제로 워크 플로의 정신을 따르지 않으므로 정리에 더 많은 시간을 할애 할 수 있습니다. 그리고 다른 사람이 신경 쓰지 않기 때문에 워크 플로와의 부적절한 상호 작용 결과를 정리하는 데 점점 더 많은 시간을 할애 할 때 다른 사람들은 워크 플로우 자체에 의문을 제기합니다.

대화부터 시작하십시오.

왜 발생하는지 알아보십시오 (동료의 시스템이 테스트에 적합하지 않습니까? 동료가 기능 분기로 불확실하거나 커밋과 푸시가 동일한 svn 사고 방식에 갇혀 있습니까?) dev / staging / prod에서 문제가 발생하는 이유를 변경할 수 있는지 확인하십시오 (동료를 평가 한 것보다 로컬에서 테스트하는 것이 더 좋을 경우 동료가 원하는 것을 수행 할 가능성이 더 높습니다).

문제를 해결할 수없고 의견이 다를 경우 다음 회고 회의에서 팀 전체 토론을 예약하고 동료의 행동과 생각을 확인하십시오. 귀하의 사례를 제시하되 합의에 귀를 기울이십시오. 어쩌면 팀은 텍스트 픽스를 로컬에서 테스트하지 않아도된다고 말하고 테스트되지 않은 큰 기능은 사용하지 않는 규칙이 있습니다. 회의에 기록하고 각 환경에서 허용되는 사항을 총괄적으로 결정한 내용을 읽습니다. 검토하기 위해 몇 달 안에 날짜를 설정하십시오.

직장에서는 Gerrit 을 사용하여 이것을 피할 수 있습니다. Gerrit는 기본적으로 "마스터"라고하는 메인 / 프로덕션 Git 브랜치의 게이트 역할을하는 코드 검토 시스템입니다. 코드 리뷰가 있습니까? 개인적으로 예외적으로하는 것처럼 들립니다. Gerrit를 사용하면 사용자와 동료가 코드 검토 프로세스를 만족스럽게 수행 한 후 Gerrit가 마스터 지점으로 병합되는 일종의 준비 지점으로 이동합니다. 누구나 Gerrit를 CI 서버에 연결하여 변경 사항을 검토하기 위해 이메일을 받기 전에 단위 테스트를 실행할 수 있습니다. CI 도구를 설정할 수있는 서버가없는 경우 Codeship 은 개념 증명으로 사용할 멋진 무료 계획이 있습니다.

마지막으로, 코드 검토 및 단위 테스트에서 살아남은 승인 된 빌드 제품에서만 프로덕션 배포를 자동화해야합니다. 이것에 대한 멋진 기술이 나오고 있습니다. 화염 미끼가 될까봐 두려워하지 않습니다.

해결책으로 상사에게 가십시오. 이것은 당신에게도 적용되며 동료를 처벌하는 것이 아니라 모든 사람의 코드 품질을 향상시키는 방법입니다.

나는 이것을 인간적인 문제로 본다. 프로세스는 존재하고 도구는 존재하지만 프로세스는 따르고 있지 않다.

나는 다른 사람들이 문제의 개발자는 단지에 붙어 확실히 가능하다는 가능성에 대해, 여기에서 말한 동의 SVN의 사고 방식, 잘 그는 생각할 수 있다 과정을 다음과 같습니다.

나는 이런 종류의 문제를 해결하는 가장 좋은 방법, 특히 명백한 우월성이 없을 수있는 경우, 처벌이나 접근 철폐를 중심으로하지는 않는다. 그 과정 (항상 하나가 있었고 나는 전에 그 사람이었습니다), 당신은 가장 많은 열을 순경 할 것입니다. 그것은 사람들이 프로세스에 대해 먼저 동의하도록하는 것을 중심으로합니다.

프로덕션에서 주요 사건이 발생한 후 "교사 학습"유형의 회의와 같은 구조화 된 회의가 매우 유용 할 수 있습니다. 문제가되는 개발자, 코드 검토, 단위 테스트, 포괄적 인 테스트 등을 포함하여 모든 사람들이 동의 할 수 있도록 항상 시도해야합니다 (스테이지 환경에 대한 아이디어도 여기에서 시작할 수 있습니다). 어렵지 않아야하며 매우 합리적입니다. 그런 다음 팀에게 어떻게해야하는지에 대한 몇 가지 확실한 규칙을 만들어 내도록 요청하십시오. 문제를 일으킨 개발자가 더 많이 기여할수록 규칙을 고수하는 느낌이 더 커지고 왜 그들의 행동이 문제가되는지 알게됩니다.

마지막 요점은 결코 "글쎄요, 예전보다 낫습니다!" 덫. 항상 개선의 여지가 있습니다. 내 경험에 비추어 볼 때, IT 업계의 사람들은 약간의 개선 후에 그들이 얻은 것에 정착하기 시작하는 것이 일반적입니다. 그런 다음 갑자기 위기 지점에 다시 올 때까지 정착이 계속됩니다.

특히 소규모 팀 에서는 드문 일이 아닙니다 . 그것에 대해 크게 다루지 말고 비공식적 인 규칙을 만드십시오.

빌드를 깨고 도넛을 가져옵니다.

1) 일주일에 두 번 도넛을 얻거나 2) 표준을 준수합니다.

회의에서 가져와 비판적으로도, 이름으로 사람을 언급하지 말고 "버전 제어 및 배포 표준을 도입 한 이후로 상황이 훨씬 쉬워졌고 서버가 예전보다 더 많은 시간이되었습니다. 그러나 적절한 테스트없이 바로 가기를 제출하고 제출하고 싶은 유혹이 있지만 도박이지만 서버는 온라인 상태입니다. 지금부터 우리 중 누군가가 서버를 손상시키는 코드를 제출하면 담당자가 가져옵니다. 다음날 팀을위한 도넛. "

원한다면 도넛을 다른 것으로 대체하고 비싸지 마십시오. 팀 전체의 점심이 너무 비싸지 만 5 달러짜리 도넛이나 과일 / 채소 트레이 또는 칩과 딥 등은 아마도 성가신 일입니다. 팀이나 회사에서 멀어지게하는 부담을주지 않으면 서 테스트 건너 뛰기의 편의성에 대비하여 실제로 위험을 평가할 수있을 정도로 충분합니다.

자, 어떻게 그들을 강제 할 수 있습니까?

동료를 강요하는 대신 관점에서 사물을 보도록하십시오. 이것은 모두에게 훨씬 쉬운 일이 될 것입니다. 어느 날로 나를 이끌어 ...

이 행동을 어떤 식 으로든 처벌하거나 가능한 한 불쾌하게 만들고 싶습니다.

라이브 서버에서 문제가 발생하는 이유는 무엇입니까? 그가 모르는 것을 알고 있습니까? 당신이 어떻게 당신이 일을 볼 수 있도록 할 수 있습니까?

당신이 이것으로 성공한다면, 당신은 그를 최고로 이끌어 낼 것이며 당신은 결코 생각하지 못한 문제에 대한 해결책을 찾을 것입니다.

일반적으로 사람들과 함께 문제를 이해하지 못하는 프로세스로 강요하는 대신 문제를 해결하기 위해 노력하십시오.

일어날 수있는 최악의 상황은 무엇입니까? 이전 버전을 복원하여 데이터베이스에서 임의의 레코드를 수정하는 버그를 해결할 수있을 정도로 충분한 백업이 있습니까?

레코드 ID를 사용하는 버그가 있고 실수로 센트 단위의 청구 금액이 레코드 ID에 사용 된 변수에 저장되어 있다고 가정 해 봅시다. 따라서 12.34 달러를 지불하면 ID가 1234 인 레코드가 수정됩니다. 버그가 감지 될 때까지 소프트웨어가 몇 시간 동안 실행되면 복구 할 수 있습니까? (올바른 레코드와 레코드 1234가 모두 업데이트되면 레코드 1234가 사용될 때만이를 감지하므로 꽤 오랫동안 탐지되지 않을 수 있습니다).

이제 동기 부여가 많은 개발자에게 이것에 대해 어떻게 생각하는지 물어보십시오. 분명히 그는 과거에 그렇게했기 때문에 결코 실수하지 않는다고 주장 할 수 없습니다.

다양한 가능한 프로세스 및 기술 솔루션을 명확하게 이해합니다. 문제는 동료를 관리하는 방법입니다.

이것은 본질적으로 변경 관리 연습입니다.

먼저, 창업자와 조용히 한 마디로 당신의 견해에 동조했는지 확인하십시오. 생산 중단이 발생하면 설립자가 그 문제에 크게 관심을 갖고 변화를 원할 것으로 기대합니다.

둘째, 소규모 팀에서 일하고 전체 팀이 프로세스 개선에 참여하도록 노력하는 것이 좋습니다.

정기적 (예 : 매주) 프로세스 회고를 설정하십시오. 전체 팀을 구성하십시오.

• 문제 식별
• 업무 관행 개선을위한 자원 봉사 아이디어
• 그러한 관행을 이행하는 데 관여

자연스럽게 팀 전체가 개선 된 관행을 준수 할 수 있도록 도와야합니다.

몇 가지 문제를 확인했다고 생각합니다.

1. 코드를 체크인 할 수있는 권한이있는 사람이라면 누구나 코드를 확인할 수있는 것처럼 들립니다.

솔직히 나는 설정이 미친 것 같아요. 최소한 수동으로 생산 푸시를 트리거 할 수있는 사람들은 신뢰할 수있는 사람들의 집합으로 제한되어야 완전히 철저하게 검토하고 푸시를 트리거하기 전에 (에 관계없이 변경 사항을 저술 한 사람의) 모든 아웃 바운드 변경 사항을 테스트 할 수 있습니다. 코드를 체크인 할 수있는 권한을 가진 사람에게 임의로 생산 푸시를 유발할 수있는 권한을 부여하는 것은 문제를 요구합니다. 부주의하거나 무능한 개발자뿐만 아니라 귀하의 계정 중 하나를 손상시키는 불만이있는 제 3 자 또는 악의적 인 제 3 자로부터도 마찬가지입니다.

그리고 푸시 버튼 프로세스를 사용하여 체크인되는 모든 변경 사항을 배포하려면 포괄적 인 자동화 된 테스트 제품군이 있어야하며 버튼을 누르면 해당 테스트를 실행해야합니다. 모든 테스트는 실패합니다!). 프로세스는 피상적으로 테스트되지 않은 코드가 처음에 프로덕션 시스템에 배포되는 지점에 도달하도록 허용해서는 안됩니다.

동료는 코드를 먼저 테스트하지 않고 코드 체크인과 관련하여 큰 실수를 범했습니다. 조직은 어떤 상황에서도 테스트되지 않은 코드가 프로덕션에 도달 할 수 있도록하는 배포 프로세스를 채택함으로써 훨씬 더 큰 실수 를 겪었습니다.

따라서 비즈니스의 첫 번째 순서는 배포 프로세스를 수정하는 것입니다. 프로덕션에 대한 푸시를 유발할 수있는 사람을 제한하거나 합리적인 배포 량의 테스트를 자동화 된 배포 프로세스 또는 둘 다에 통합하십시오.

2. 명확하게 정의 된 개발 표준 / 원칙을 설정하지 않은 것 같습니다.

특히, " 완료 "에 대한 명확한 정의 가 누락되었거나 "코드가 테스트되었습니다"를 포함하지 않는 정의를 사용하여 코드를 검사 / 제작할 때 코드를 확인 / 배포 할 때 중요한 요소로 사용하는 것 같습니다. 이 코드를 가지고 있다면 "좋은 코드는 이런 식으로 생산되지 않는다"는 대신 "이 코드는 우리 모두가 동의 한 최소 표준을 충족하지 못하므로 더 나은 코드가 필요하다"고 말할 수 있습니다. 미래".

개발자가 기대하는 것과 명확하게 유지해야 할 표준 및 품질 수준을 명확하게 전달하는 문화를 구축해야합니다. 최소한 수동 테스트 (또는 빌드 / 배포 프로세스의 일부로 실행할 수있는 자동화 된 테스트 케이스)를 포함하는 완료 정의를 설정하면 도움이됩니다. 빌드를 깨뜨린 결과를 초래할 수 있습니다. 또는 생산 시스템을 깨뜨리는 더 심각한 결과. 이 두 가지 요소는 실제로 독립적이어야하며 빌드와 프로덕션 시스템을 동시에 분리하는 것은 불가능합니다 (파손 된 빌드는 배치 할 수 없으므로).

회사에서 Continuous Integration + Peer Review 프로세스를 통합해야합니다. Bitbucket을 사용하면 쉽게 할 수 있습니다.

그리고 다른 사용자가 제안한 개발 서버에 +1합니다.

그와 무례하지 마십시오, 그것은 단지 당신의 업무 관계를 해칠 것입니다.