연재의 마지막 회차입니다. 지금까지 명령을 익히고, 스크립트를 쓰고, 멱등하게 만들고, 자체 명령으로 승격하고, 정시에 도는 크론까지 놓았습니다. 남은 것은 이것들을 사람이 기억하지 않아도 되게 만드는 일입니다.
싼 검사부터 순서대로
파이프라인 설계의 첫 원칙은 빠르고 싼 검사를 앞에 두는 것입니다. 워드프레스를 띄우는 단계는 느리므로, 그 앞에서 잡을 수 있는 것은 전부 앞에서 잡습니다.
4회차에서 본 자립형 스크립트가 여기서 값을 합니다. 워드프레스 파일을 include 하지 않고 순수 PHP 로 도는 검사는 데이터베이스도 설치도 필요 없이 몇 초 만에 끝나므로, 규칙 위반의 대부분을 첫 단계에서 걸러 냅니다.
일회용 워드프레스 한 벌
그다음 단계에서는 실제로 워드프레스를 세웁니다. 매 실행마다 새로 만드는 것이 핵심입니다 — 남아 있는 상태가 없어야 검사 결과를 믿을 수 있습니다.
wp core download --path=wp
wp config create --path=wp --dbname=ci --dbuser=ci --dbpass=ci --dbhost=127.0.0.1
wp core install --path=wp --url=http://localhost --title=CI --admin_user=ci --admin_email=ci@example.test --skip-email
wp theme activate acme-child --path=wp
wp plugin activate acme-core --path=wp
--skip-email 을 잊지 마세요. 없으면 설치 알림 메일을 실제로 보내려 시도합니다. 그리고 이 단계는 절대 프로덕션 데이터베이스를 향하지 않습니다 — 자격증명은 저장소가 아니라 파이프라인의 비밀 저장소에 둡니다.
실제로 거는 검사
여기부터가 연재의 결과물입니다. 앞 회차에서 만든 것들이 그대로 검사 항목이 됩니다.
wp plugin list --status=active --field=name --path=wp
wp option get blog_public --path=wp
wp core verify-checksums --path=wp
wp plugin verify-checksums --all --path=wp
wp eval-file bin/lint-content.php --path=wp
wp acme checklist run --format=json --path=wp
verify-checksums 는 특히 값이 큽니다. 코어와 플러그인 파일이 배포본과 다른지를 대조하므로, 서버에서 누가 직접 파일을 고쳤는지가 드러납니다. 업데이트 때 그 수정이 사라지고 원인을 못 찾는 상황을 미리 막습니다.
실패 재현을 위해 wp db export 결과를 산출물로 남겨 두면, 실패한 빌드의 상태를 그대로 내려받아 로컬에서 열어 볼 수 있습니다.
종료코드가 계약이다
파이프라인은 로그를 읽지 않습니다. 종료코드만 봅니다. 그래서 6회차에서 정한 구분이 여기서 그대로 의미를 갖습니다 — WP_CLI::error() 로 끝난 명령은 종료코드 1 로 빌드를 떨어뜨리고, warning 은 로그에 남지만 통과시킵니다.
즉 명령을 만들 때 무엇을 error 로 부를지 정하는 일이 곧 무엇을 배포 차단 사유로 삼을지 정하는 일이었습니다. 이 결정을 뒤로 미루면 파이프라인이 “빨간불이 자주 뜨지만 아무도 안 본다” 상태가 됩니다.
플러그인 하나가 부팅에서 죽는 경우에는 --skip-plugins --skip-themes 로 최소 진입을 확보해 나머지 검사를 이어가되, 그 사실 자체를 실패로 기록합니다. 우회는 진단을 위한 것이지 통과를 위한 것이 아닙니다.
연재를 마치며
여덟 회차 동안 클릭을 명령으로, 명령을 스크립트로, 스크립트를 명령으로 승격하고, 마지막에는 그 전부를 파이프라인에 넘겼습니다. 관통하는 원칙은 하나였습니다 — 한 번 확인한 것은 다시 사람이 기억하지 않게 만든다.
워드프레스는 이런 작업을 하기에 좋은 도구입니다. 공식 CLI 가 있고, 데이터 모델이 열려 있고, 훅으로 어디든 붙일 수 있습니다. 문제가 생기는 것은 도구가 부족해서가 아니라 이 절차가 없어서입니다.
운영 중인 사이트에 이 절차를 한 번에 깔고 싶다면 최적화 지원 사업이 업그레이드 · 성능 · 보안 점검을 한 건으로 처리하고, 우리가 실제로 어떤 순서로 작업하는지는 작업 과정에 단계 그대로 공개돼 있습니다. 연재 전체의 배경이 되는 글들은 개발 워크플로우 아카이브에 모여 있습니다.