에이전트가 운영 환경을 망가뜨린 것이 아닙니다. 파이프라인이 망가뜨린 것입니다.

에이전트가 운영 환경을 망가뜨린 것이 아닙니다. 파이프라인이 망가뜨린 것입니다.

많은 팀이 풀 리퀘스트(PR)를 생성하기 위해 에이전트를 사용합니다. 린팅, 테스트, 빌드를 확인하기 위해 CI를 사용하죠. 그런 다음, 예약된 작업(scheduled job)이 스테이징에서 운영 환경으로 코드를 이동시킵니다. 이러한 설정은 결국 실패하게 되어 있습니다.

문제는 악의적인 에이전트가 아닙니다. 문제는 잘못된 프로세스입니다. 여러분은 서로 다른 두 가지 질문을 하나의 게이트로 합쳐버렸습니다:

• 이 코드가 CI를 통과했는가?
• 지금 사람이 보기에 안전한가?

이 둘은 같은 것이 아닙니다. CI는 코드가 작동하는지 확인합니다. 기능이 고객에게 제공될 준비가 되었는지는 확인하지 않습니다.

만약 파이프라인이 '머지(merged)'와 '라이브(live)'를 동일하게 취급한다면, 문제가 있는 것입니다. 여러분은 의도하지 않았음에도 지속적 배포(continuous deployment)를 선택한 셈입니다.

이 두 이벤트를 분리해야 합니다.

이를 위해 피처 플래그(feature flags)를 사용할 수 있습니다. 피처 플래그는 그저 불리언(boolean) 값과 if 문일 뿐입니다. 시작할 때 비싼 도구가 필요하지는 않습니다. 간단한 설정값이나 환경 변수만으로도 충분합니다.

저의 설정은 다음 규칙을 따릅니다:

• PR은 main 브랜치에 머지되지만, main이 곧 라이브 상태는 아닙니다.
• 별도의 릴리스 단계를 통해 main을 운영(production) 브랜치로 승격시킵니다.
• 반드시 명시적으로 실행(go)을 명령해야 합니다. 크론 잡(cron jobs)이나 타이머를 사용하지 않습니다.
• 릴리스는 빌드가 트래픽을 처리할 수 있을 때까지 대기합니다.
• 자동화된 체크가 주요 엔드포인트(endpoints)를 호출하여 사이트가 정상 작동하는지 확인합니다.
• 사람이 변경 사항에 대해 최종 수동 점검을 수행합니다.

이를 통해 게이트가 만들어집니다. 사용자가 무언가를 보기 전에 사람, 기계, 그리고 또 다른 사람이 모두 '아니오(no)'라고 말할 기회를 갖게 됩니다.

만약 버그가 여전히 사용자에게 도달한다면, 빠르게 되돌려야(revert) 합니다. 이를 위해 데이터베이스 마이그레이션 시 '확장 및 축소(expand and contract)' 패턴을 따르십시오.

• 새 컬럼을 nullable로 추가합니다.
• 데이터를 백필(backfill)합니다.
• 기존 컬럼과 새 컬럼 모두에 데이터를 씁니다.
• 새 컬럼에서 데이터를 읽습니다.
• 나중에 별도의 릴리스에서 기존 컬럼을 삭제합니다.

이 과정을 건너뛰면 되돌리기(revert) 버튼은 무용지물이 됩니다. 마이그레이션 과정에서 기존 코드가 필요로 하는 컬럼을 삭제해 버리면 롤백할 수 없습니다. 그냥 장애 상태가 지속될 뿐입니다.

에이전트는 이러한 실수를 더 빠르게 발생시킵니다. 에이전트는 잘못된 프로세스를 숨겨주던 수동적인 마찰(manual friction)을 제거해 버립니다. 여러분이 건너뛰었던 규율(discipline)은 결코 선택 사항이 아니었습니다. 그저 금요일 오후 5시 이전에 사람이 실수를 발견함으로써 가려져 있었을 뿐입니다.

루프에서 사람을 제외하면, 규율은 필수 사항이 됩니다.

출처: https://dev.to/mattstratton/your-agent-didnt-break-prod-your-pipeline-did-4g9o