Smoke 호스트가 죽기 전에 종료 코드를 저장하기

월요일에 팀 위키를 열었는데 금요일 날짜의 메모가 붙어 있고, 에이전트 패치가 무료 박스에서 통과했다고 적혀 있습니다. 호스트 링크는 더 이상 연결되지 않고, 공유 모델 스레드는 이미 다른 내용으로 넘어갔으며, 풀 리퀘스트(pull request)도 여전히 완료된 것처럼 보입니다. 온라인에 있던 누구에게서도 정확한 명령어, 확인된 diff, 또는 종료 코드(exit code)를 복구할 수 없습니다. 이 누락된 증거가 바로 다음 작업을 시작하기 전에 이 플레이북이 방지하도록 작성된 실패 사례입니다.

생성된 초안과 클릭 가능한 페이지는 대부분의 팀이 실제로 실행한 내용을 기록하기도 전에 검토 단계에 도달합니다. 클릭 가능한 검토 페이지는 증거가 아니며, 사라진 smoke 호스트는 여전히 디버깅할 수 있는 실패한 테스트도 아닙니다. 귀하의 팀은 박스가 회수되고 모델 세션이 손이 닿지 않는 곳으로 스크롤되기 전에 완료되는 캡처 단계가 필요합니다. 아래 섹션에서는 역할, 인계(handoff) 코멘트, 그리고 오늘 위키에 붙여넣을 수 있는 한 페이지짜리 실행 방법을 설명합니다.

기다리면 사라지는 것들

임시 검사 호스트(Ephemeral check hosts)는 저렴하고 일회용이기 때문에 유용하지만, 이것이 장기적인 아카이브로는 부적합한 이유이기도 합니다. 무료 서버 옵션은 재부팅되거나 만료되거나 공유 로테이션의 다음 사람에 의해 재사용될 수 있습니다. 무료 모델 세션은 특정 플래그가 선택된 이유를 설명했던 이전 대화 내용을 삭제할 수 있습니다. 로그를 복사하기 위해 월요일 스탠드업까지 기다린다면, 남는 기록은 모호한 문장뿐입니다.

박스를 다음 주 검토자가 신뢰할 시스템의 기록(system of record)이 아니라 작업대(workbench)로 취급하십시오. 저장소(repository), 또는 그 옆에 있는 위키 페이지에는 버전(rev), 명령어, 종료 코드, 그리고 제한된 로그가 포함되어야 합니다. 한 번에 복사할 수 없는 것은 채팅에서 녹색 줄로 암시하는 대신 누락되었다고 표시해야 합니다. 전체 머신 이미지(machine image)를 보존하려고 하는 것이 아닙니다. 그 목표는 금요일 검사를 하기에 너무 큽니다.

팀원이 동일한 검사를 다시 실행하거나 주장을 깔끔하게 거부할 수 있도록 충분한 정보를 보존하려고 노력하고 있습니다. 이처럼 좁은 목표는 다른 사람이 같은 호스트가 필요하기 전에 실행을 완료할 만큼 짧게 유지합니다. 나중에 읽는 사람은 존재했던 파일에 대한 이야기가 아니라, 실제로 파일을 봐야 합니다. 파일이 없으면, 채팅 분위기가 자신감 있어 보였더라도 주장은 불완전합니다.

역할과 인수인계

팀원이 적더라도 위키 페이지에 세 개의 이름을 지정해야 합니다. 러너(runner)는 검사를 실행하고 증거 파일이 브랜치에 존재할 때까지 호스트를 닫기를 거부합니다. 리뷰어(reviewer)는 그 증거 파일을 수락하거나 거부하며, 대신 채팅 요약은 받아들이지 않습니다. 리클레이머(reclaimer)만이 박스를 파괴하거나 재사용할 수 있는 사람이며, 이는 리뷰어가 증거가 완료되었다고 표시한 후에만 가능합니다.

인수인계는 호스트가 이미 사라진 후에 잡는 회의가 아니라, 단일 서면 댓글이어야 합니다. 러너는 증거 경로(proof path), git 리비전(git revision), 그리고 종료 코드(exit code)를 붙여넣은 다음, 이름으로 리뷰어를 태그합니다. 리뷰어는 '증거 수락' 또는 아직 누락된 필드 목록을 간략하게 작성하여 답장합니다. 리클레이머는 그 답변을 기다렸다가, 다음 러너가 더러운 호스트(dirty host)를 상속받지 않도록 회수 시간(reclaim time)을 기록합니다.

만약 한 사람이 이 모자 중 두 개를 써야 한다면, 여전히 페이지에 두 역할 이름을 작성해야 합니다. 두 번째 행동은 같은 사람이 나중에 수행하더라도 별도의 단계처럼 보여야 합니다. 이러한 분리를 건너뛰는 것이 피곤한 러너가 박스를 회수했다가 로그가 복사되지 않았다는 것을 발견하는 방식입니다. 다음 월요일 독자가 누가 아직 답장을 해야 하는지 알 수 있도록 날짜 옆에 이름을 작성하세요.

붙여넣을 수 있는 원페이지 실행

다음 8단계를 위키에 이 클래스의 검사(check)를 위한 유일한 성공 경로로 붙여넣으십시오. 순서와 모순되는 부가 설명을 추가하지 마십시오. 왜냐하면 그 순서가 재할당 전에 증명(proof)을 앞세우는 것이기 때문입니다. 각 단계는 눈에 보이는 아티팩트(artifact)를 남겨야 하므로, 나중에 읽는 사람이 실행이 어디에서 멈췄는지 볼 수 있어야 합니다. 페이지가 너무 길지 않게 유지하여 새로운 러너(runner)가 워크스루(walkthrough)를 요청하지 않고도 따라올 수 있게 하십시오.

1. 작동하는 브랜치(working branch)를 생성하고, 검사를 시작하기 전에 증명 노트에 git rev-parse HEAD의 출력을 기록하십시오.
2. 작업 디렉터리를 포함하여 실행할 정확한 명령어를 작성하고, 나중에 채팅에서 그 명령어를 바꿔 말하지 마십시오.
3. 임시 호스트(ephemeral host)에서 검사를 실행하고, 경계가 지정된 로그(bounded log)를 증명 디렉터리 아래의 파일로 tee 하십시오.
4. 모델이 명령어 완료 후 작성한 문장으로부터가 아니라 셸 자체로부터 나온 종료 코드(exit code)를 기록하십시오.
5. 증명 노트와 경계가 지정된 로그를 브랜치에 복사한 다음, 메시지에 함께 리비전(revision)과 함께 커밋하십시오.
6. 증명 경로(proof path), 리비전(revision), 그리고 종료 코드를 포함하는 핸드오프 댓글(handoff comment)을 게시하고, 명시된 리뷰어(named reviewer)를 태그하십시오.
7. 누군가가 공유 호스트를 재할당하거나 다시 이미징(reimage)하기 전에 증명 승인(proof accepted) 또는 누락 필드 목록(missing-field list)이 나올 때까지 기다리십시오.
8. 호스트가 일찍 죽으면, 증명을 불완전한 것으로 표시하고 메모리에서 로그를 재구성하는 대신 재실행을 예약하십시오.

핸드오프 댓글은 이렇게 평범하게 유지할 수 있으며, 실행이 어떻게 느껴졌는지에 대한 서사(narrative)를 추가하려는 것을 저항해야 합니다. 리뷰어가 전체 로그를 열지 않고도 스캔할 수 있도록 네 개의 필드를 펜스 블록(fenced block) 안에 넣으십시오. 상태 라인은 명시된 리뷰어가 그 문구를 되돌려 쓸 때까지 'awaiting proof accepted'로 유지하십시오. 죽은 호스트의 스크린샷을 첨부하지 마십시오. 왜냐하면 스크린샷은 다음 사람이 재실행할 수 없기 때문입니다.

proof: proof/evidence.md
rev: <git rev>
exit: <integer>
...

예시 스냅샷 스크립트

아래 스크립트는 귀하의 인프라에서 실행된 보고서가 아니라 적응할 수 있는 로컬 템플릿입니다. 출력 결과를 신뢰하기 전에 스크래치 리포지토리에서 실행하고 로그 경로를 조정해야 합니다. 이 스크립트는 리비전(revision), 명령어, 또는 종료 코드가 누락되면 증명 노트 작성을 거부합니다. 파일에 기록된 내용은 예시 캡처로 간주하고 커밋하기 전에 로그 테일을 검토하십시오.

#!/usr/bin/env bash
set -euo pipefail

...

먼저 체크를 실행한 다음, 나중에 실행될 명령어가 이를 대체할 것이므로 그 셸 종료 코드를 세 번째 인수로 전달하십시오. tee를 통해 파이프하면, tee의 종료 코드 대신 PIPESTATUS에서 체크 상태를 읽으십시오. 아래 명령어들은 미실행 예시이므로, 테스트 경로를 팀이 실제로 신뢰하는 체크로 대체하십시오. 이 스니펫을 스위트가 통과했다는 증거로 커밋하지 마십시오. 왜냐하면 이는 단순히 상태를 기록하는 방법을 보여줄 뿐이기 때문입니다.

mkdir -p proof
set +e
pytest -q tests/agent_smoke | tee proof/check.log
...

검토자는 로그 섹션에서 로그가 누락되었다고 하거나 종료 코드가 정수가 아닐 때 노트를 거부할 수 있습니다. 에이전트 경로 변경 시 증거 파일이 없을 경우 브랜치를 실패시키는 작은 CI 체크를 추가할 수 있습니다. 이 체크는 모델이 정확했음을 증명하지는 않지만, 검토 전에 누군가 결과를 캡처했다는 것은 증명합니다. 러너가 다른 형식을 만들지 않도록 위키의 여덟 단계 옆에 이 템플릿을 유지하십시오.

보존할 것과 남겨둘 것

이 실행에 대한 캡처 정책으로 표를 사용하고, 데이터 규칙이 변경될 때 다시 검토하십시오. 리비전, 정확한 명령어, 종료 코드, 그리고 짧은 로그 테일을 git 또는 위키에 보존하십시오. 전체 디스크 이미지와 박스에 있는 공급업체 캐시는 재수거(reclaimer)가 이를 지울 수 있도록 허용할 때까지 남겨두십시오. 비밀 정보, 토큰, 또는 실시간 자격 증명은 절대 커밋하지 말고, 다음 러너가 도착하기 전에 호스트에서 삭제하십시오.

무료 레인이 적합한 곳

공개: 이 문서는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다.

MonkeyCode는 초안 및 smoke host를 위해 사용할 수 있는 레인으로서 이 실행에만 속합니다. 운영자는 이러한 종류의 일회성 검사를 담을 수 있는 무료 모델 접근 및 무료 서버 옵션을 설명합니다. 본 문서는 토큰 할당량, 하드웨어 크기, 시간 제한 또는 제공이 고정된다는 약속을 인용하지 않습니다. 그러한 세부 사항은 변경될 수 있으므로, 이를 기반으로 용량을 계획하기 전에 현재 프로젝트 페이지를 읽어야 합니다.

무료 모델을 사용하여 명령어 목록을 초안 작성하고, 실행자(runner)가 정확한 명령어를 증명 노트에 붙여넣도록 하십시오. 무료 서버를 세 번째 단계의 작업대(workbench)로 사용하고, 다섯 번째 단계에서도 여전히 박스에서 증명을 복사하십시오. 만약 그날 두 가지 무료 옵션 중 어느 것이든 사용할 수 없다면, 이미 통제하는 모든 임시 호스트에서 동일한 실행이 작동합니다. 제품 언급이 제거되더라도 플레이북은 유용하게 유지됩니다. 왜냐하면 증명은 여전히 사용자의 리포지토리에 존재해야 하기 때문입니다.

이 8단계를 검사 페이지에 붙여넣고, 호스트를 할당하기 전에 현재 MonkeyCode 무료 레인 약관을 확인하십시오. 이 확인 작업을 같은 날 프로젝트 페이지에서 수행하십시오. 왜냐하면 지난달의 메모가 용량 계획이 아니기 때문입니다. 만약 페이지에 예상했던 것과 다른 제한 사항이 나열되어 있다면, 검사를 작게 줄여서 맞추거나 사용자가 통제하는 호스트로 옮기십시오.

한계점 및 건너뛰어야 할 사람

이 실행은 프로덕션 변경 통제를 대체하지 않으며, 모델 답변이 정확하다는 것을 증명하지도 않습니다. 캡처된 종료 코드는 여전히 잘못된 테스트에 속할 수 있으며, 이는 별도의 오라클 문제이므로 다른 곳에서 추적해야 합니다. 샘플 스크립트는 비밀 정보를 자동으로 제거해주지 않으므로, 부주의한 로그가 저장소로 유출될 수 있습니다. 커밋을 푸시하기 전에 모든 tail 내용을 직접 스캔하거나 이미 신뢰하는 비밀 스캐너를 사용해야 합니다.

체크가 규제된 데이터를 처리하는 경우, 또는 정책상 호스트의 보존 포렌식 이미지(forensic image)가 필요한 경우에는 이 접근 방식을 건너뛰십시오. 명령어 자체가 무해해 보여도 규칙이 위키에 명령 텍스트 붙여넣기를 금지하는 경우에는 건너뛰십시오. 아무도 검토자 역할을 할 수 없는 경우에도 건너뛰십시오. 읽히지 않은 증명 파일(proof file)은 단지 기록 보관소의 또 다른 메모일 뿐입니다. 또한, 재활용기(reclaimer)가 기계를 되찾아야 하는 시간 전에 완료될 수 없는 장기 작업에는 짧게 유지되는 박스(Short-lived boxes)도 적합하지 않습니다.

하나의 에이전트 경로와 하나의 스크래치 호스트로 시작하고, 검토자가 빠르게 읽을 수 있도록 증명 파일을 충분히 지루하게 만드십시오. 2주 후에 검토자들이 실제로 거부하는 필드가 무엇인지 살펴보고, 역할을 더 추가하기보다는 템플릿을 간소화하십시오. 원하는 습관은 간단합니다: 개정(revision), 명령어, 그리고 종료 코드가 이미 git에 들어갈 때까지는 재활용하지 않는 것입니다. 이 습관은 도구 변경에도 살아남기 때문에, 위키 페이지는 특정 공급업체의 화면보다는 증명 자체를 설명해야 합니다.