WordPress 사이트를 위한 최신 배포

게시 됨: 2022-06-30

나와 같은 경우 웹 서버에 파일을 푸시하는 첫 번째 경험은 cPanel과 같은 웹 기반 파일 관리자나 Transmit 또는 Filezilla와 같은 FTP(File Transfer Protocol) 클라이언트를 통한 것입니다. 서버에 연결하고 파일을 드래그한 다음 전송이 완료될 때까지 기다립니다.

쉽죠?

그러나 정적 HTML 파일보다 더 복잡한 작업을 시작하자마자 내 코드 배포가 훨씬 더 복잡해졌습니다. 다른 사람이 필요로 하는 파일이나 전역 포함의 세미콜론을 놓치고 흰색 화면으로 표시되면 어떻게 되나요? 전체 사이트? 그 과정에서 중요한 단계를 놓치면 어떻게 될까요?

이러한 "카우보이 코딩" 문제는 더 많은 사람, 환경 및 종속성이 관련될수록 악화됩니다. 결과적으로 이 모든 움직이는 부분을 저글링하면서 계속 진행하는 것이 점점 더 어려워집니다. 무엇보다도, 코드를 공개 하는 것이 큰 문제 가 되고 끊임없는 불안의 근원이 됩니다.

애플리케이션, 사이트 및 상점이 더욱 현대화됨에 따라 배포도 현대화해야 합니다. 버전 제어에서 지속적 배포에 이르기까지 최신 릴리스 프로세스는 배포에 대한 불안을 덜어줄 수 있습니다.

버전 관리로 변경 사항 추적

임시 업데이트와 카우보이 코딩에서 벗어나는 첫 번째 단계는 Git과 같은 도구를 사용하여 사이트를 버전 제어하는 ​​것입니다.

버전 제어를 사용하면 무엇이 변경되었는지, 누가 변경했는지 볼 수 있으며 분기를 사용하여 동시에 여러 변경 세트에 대해 작업할 수도 있습니다. 결과적으로 작업을 덮어쓰지 않고 파일 간의 충돌이 명확하게 강조 표시됩니다.

이전에 Git으로 작업한 적이 없다면 두려워하지 마십시오. Git에 대한 소개와 고급 Git 워크플로에 대한 게시물을 모두 작성했습니다.

추적할 대상 결정

버전 관리 하에 사이트를 이동할 때 추적 하지 않는 항목은 수행하는 작업만큼 중요합니다.

일반적으로 버전 관리는 도구나 프로세스에서 생성된 자산이 아니라 소스 코드를 추적하기 위한 것 입니다. 여기에는 연결/축소된 CSS 및 JavaScript, 외부 종속성 등이 포함됩니다. 집합적으로 이러한 항목을 아티팩트 라고 합니다.

예를 들어 Sass와 같은 CSS 전처리기를 사용하는 경우 생성된 CSS 파일은 버전 제어 하에 추적 되지 않아야 합니다. 쉽게 재현할 수 있을 뿐만 아니라 읽기 어렵고 여러 개발자가 관련된 경우 병합 충돌의 일반적인 원인입니다.

종속성(라이브러리, WordPress 플러그인 등)의 경우 저장소에서 책임지지 않는 코드를 번들로 묶는 대신 Composer 및 WPackagist와 같은 도구를 활용하십시오.

또한 Git 리포지토리에는 암호, 개인 SSH 키 또는 비밀 로 간주되는 기타 기밀 정보가 포함되어서는 안 됩니다. 리포지토리 복사본이 있는 모든 개발자는 해당 컴퓨터에 민감한 정보를 갖게 되기 때문입니다.

저장소 구조화

WordPress 또는 WooCommerce 사이트용 Git 리포지토리를 설정할 때 일반적으로 wp-content/를 리포지토리의 루트로 처리하는 것이 가장 좋습니다. 왜냐하면 일반적으로 이 디렉토리 위의 파일을 건드리지 않기 때문입니다.

사이트에서 사용하지만 코드를 유지 관리하지 않는 플러그인과 테마는 외부 종속성이므로 Composer를 통해 로드해야 합니다. 마찬가지로 처리된 CSS 및 JavaScript 파일은 .gitignore 파일을 통해 제외되어야 합니다. 이러한 아티팩트는 릴리스 프로세스의 일부로 빌드될 것이기 때문입니다.

GitHub에서 시작하는 데 사용할 수 있는 무료 리포지토리 템플릿이 있습니다.

CI/CD 소개

소프트웨어 배포와 관련하여 CI( 지속적 통합 ) 및 CD( 지속적 전달 )라는 두 가지 중요한 용어를 이해해야 합니다.

이 두 용어는 밀접하게 관련되어 있어 종종 집합적으로 "CI/CD"라고 하며 변경 사항이 흐르는 경로는 "CI/CD 파이프라인"이 됩니다. 이 파이프라인은 일반적으로 다음과 같은 형식을 취합니다.

  1. 릴리스 빌드: 종속성(Composer, npm 등)을 설치한 다음 아티팩트(Webpack, Grunt, Sass 등)를 빌드합니다.
  2. 빌드 테스트: 단위 테스트 실행, 코딩 표준 확인, 정적 코드 분석 수행 등
  3. 하나 이상의 환경에 릴리스 배포

지속적인 통합 은 변경 사항이 기존 기능을 손상시키지 않도록 코드를 지속적으로 테스트하여 새로운 변경 사항이 기존 코드베이스와 완전히 통합 되도록 하는 프로세스입니다. 새로운 변경 사항이 푸시될 때마다 "빌드를 깨뜨리지" 않는지 확인하기 위해 검사가 실행됩니다.

지속적인 통합이 유용하려면 이러한 검사가 자동화 되어야 합니다. 예를 들어 단위 테스트 모음이 있는 경우 새 pull 요청이 열릴 때마다 이 테스트 모음을 실행하도록 선택하여 코드가 프로덕션에 도착 하기 전에 가능한 손상을 경고할 수 있습니다.

그러나 다음을 포함하여 코드에 대해 자동으로 실행할 수 있는 여러 "코드 없는" 검사가 있으므로 지속적인 통합은 단위 테스트에 국한되지 않습니다.

  • 코딩 표준 검사(PHP_CodeSniffer, PHP Coding Standards Fixer)
  • 정적 코드 분석(PHPStan, 시편)

푸시할 때마다 이러한 검사를 자동으로 실행하면 모든 코드가 동일한 검사를 통해 실행되어 통과하지 못한 코드가 릴리스되지 않도록 합니다.

반면에 지속적인 전달 은 주어진 순간에 코드를 "전달"(배포)할 수 있어야 한다는 개념입니다. 이를 수행하려면 버튼 클릭으로 코드를 프로덕션으로 원활하게 이동하는 스크립트된 배포 프로세스가 있어야 합니다.

배포를 스크립팅하면 정기적으로 일관되게 배포할 수 있습니다. 모든 배포는 이전 배포와 동일하게 작동 해야 합니다. 결과적으로 팀은 더 높은 수준의 자신감을 가지고 더 정기적으로 배포할 수 있고 누군가가 도중에 한 단계를 놓쳤다는 걱정을 덜 수 있습니다. 일부 팀의 경우 하루에 수십 번(또는 수백 번) 배포하는 것이 일반적입니다!

사이트에 따라 "다른 CD"인 지속적인 배포 를 살펴볼 수도 있습니다. 지속적 전달과 매우 유사하지만 이 모델에서는 분기에 대한 모든 푸시가 자동으로 배포됩니다. 이것은 분기된 버전 제어 체계(예: Github Flow)를 사용할 때 매우 강력할 수 있지만 릴리스 기간을 예약하거나 기본 분기에서 모든 작업을 수행해야 하는 경우에는 바람직하지 않을 수 있습니다.

CI/CD를 사용하여 WordPress 또는 WooCommerce 사이트 배포

이제 기본 용어를 이해했으므로 일반적인 WordPress 또는 WooCommerce 사이트를 배포하는 방법을 살펴보겠습니다.

이 연습에서는 WP Pusher 뒤에 있는 동일한 사람들의 WordPress 개발자 요구 사항을 중심으로 설계된 CI/CD 도구인 Branch를 사용할 것입니다. 무엇보다도 Branch는 Nexcess에 배포하기 위한 기본 제공 지원을 제공합니다!

시작하려면 GitHub, GitLab 또는 Bitbucket 계정을 연결한 다음 첫 번째 사이트를 만들어 Branch에 가입하세요.

다음으로 사이트를 구축하는 데 필요한 모든 단계를 구성하려고 합니다. Branch는 일반적인 작업(Composer 종속성 설치, Webpack 실행 등)을 위한 여러 "레시피"를 제공하지만 사용자 정의 단계를 원하는 만큼 추가할 수 있는 기능도 제공합니다.

사이트 구축에 필요한 단계를 설명하고 나면 파이프라인의 다음 단계인 테스트로 넘어갈 수 있습니다.

사이트에 대한 자동화된 테스트 제품군이 이미 있는 경우 필요한 명령을 실행하도록 Branch에 지시할 수 있습니다. 아직 테스트가 없더라도 Branch를 사용하면 린트, 코딩 표준 및 호환성 검사를 쉽게 추가할 수 있습니다.

이제 종속성을 설치하고 모든 것을 빌드하고 테스트를 통과했으므로 코드를 프로덕션 환경에 적용할 시간입니다!

Branch에는 Nexcess(및 기타 주요 호스팅 제공업체)에 배포하기 위한 레시피가 포함되어 있으며 두 플랫폼을 쉽게 연결할 수 있습니다.

  1. Branch 대시보드에서 사이트를 선택하고 "설정"을 클릭한 다음 Branch 사이트의 공개 SSH 키를 가져옵니다.
  2. Nexcess 포털 내의 키 목록에 이 공개 키를 추가하십시오.

Branch가 Nexcess 사이트와 통신할 수 있게 되면 "Nexcess" 배포 레시피를 선택하고 몇 가지 세부 정보를 입력할 수 있습니다.

  1. 사이트의 호스트 이름 및 사용자 이름(사이트의 "액세스" 화면에서 Nexcess 포털을 통해 사용 가능)
  2. 배포할 웹 루트입니다. git repo가 ​​wp-content/ 디렉토리 역할을 하는 경우 이 값은 "public_html/wp-content"여야 합니다.
  3. 배포하려는 파일(일반적으로 기본값 "*"이면 충분함)
  4. 이 환경에 배포할 git 분기

"Git branch" 설정이 특히 중요합니다. 이렇게 하면 다른 분기에 대해 다른 배포를 지정할 수 있습니다. 예를 들어, 스테이징 환경에 배포하는 "스테이징" 분기가 있을 수 있으므로 변경 사항을 적용하기 전에 테스트할 수 있습니다.

Branch는 기본적으로 연속 배포 모델을 사용하며, 여기서 파이프라인은 지정된 분기에 푸시할 때마다 실행됩니다. 지속적인 전달 모델(일부 수동 조치를 취해야 함)을 더 선호하는 경우 릴리스할 준비가 되었을 때만 병합되는 "프로덕션" 분기를 유지 관리하는 것을 고려할 수 있습니다.

이 시점에서 git 저장소를 빌드하고 Nexcess에 배포하도록 Branch를 구성해야 합니다! 사이트의 "파이프라인" 페이지에서 "배포 실행" 버튼을 클릭하거나 Git 리포지토리로 푸시하여 첫 번째 배포를 트리거할 수 있습니다.

릴리스 프로세스 사용자 정의

Branch의 정말 멋진 기능 중 하나는 배포 후 사이트의 개체 캐시를 자동으로 지우는 것과 같이 성공적인 배포 후 추가 단계를 구성하는 기능입니다. 이는 "기타" 아래의 WP-CLI 레시피를 사용하여 수행할 수 있습니다.

호스트와 사용자 이름은 일반적으로 배포 단계에서 사용한 것과 동일하며 필요한 만큼 명령을 연결할 수 있습니다.

결론

카우보이 코딩 장난 및/또는 불안으로 가득 찬 릴리스로 여전히 어려움을 겪고 있다면 Branch를 살펴보고 배포를 쉽게 만드십시오!