Bitbucket을 사용한 WordPress 지속적인 배포 및 버전 제어

게시 됨: 2022-03-11

좋아요, 여러분. 화낼 시간입니다.

나와 같은 사람이라면 WordPress 개발 기간의 첫 번째 구간인 "카우보이 코딩"을 보냈습니다. 사이트 전체는 귀하의 소중한 방문자에게 모두 표시됩니다.

이것은 아드레날린이 손가락을 통해 펌핑되어 잊혀진 세미콜론을 두드리는 것과 같이 절대적으로 스릴 있었지만 0명 이상의 방문자(실제로 가동 중지 시간을 알아차린)가 있는 사이트에서는 이것이 문제가 되기 시작할 것입니다. 나무가 쓰러지고 아무도 그것을 들을 사람이 없으면 소리가 나는가? 구독하는 인류 이론에 따라 다릅니다.

그러나 사이트가 충돌하고 누군가가 그것을 보기 위해 거기에 있다면 그들은 확실히 소리를 낼 것입니다.

WordPress 연속 배포가 잘못되었습니다.

준비 사이트에 들어가 변경 사항이 있을 수 있는 WordPress 설치(최소한 이론상)를 복제한 다음 모든 것이 작동하는 것으로 확인되면 라이브 사이트에서 다시 수행합니다. 이것이 방문자를 진정시키는 동안 우리 개발자들은 약간의 소음을 일으키기 시작했습니다. 갑자기 두 사이트를 추적하고 두 사이트 간에 코드가 수동으로 동기화되었는지 확인하고 모든 항목을 다시 테스트하여 실제 사이트에서 작동하는지 확인해야 했습니다. "실시간에 이것을 변경했는지 확인하십시오"와 "코드를 복사하기 전에 스테이징 사이트에서 이것을 토글해야 합니다"라는 길고 지저분한 목록은 말 그대로 신경을 곤두서게 만들었습니다. 이 시스템의 백업도 악몽이었습니다. "my-theme-staging-1" 및 "my-theme-live-before-menu-restyle-3" 등의 이름을 가진 수많은 폴더.

더 나은 방법이 있어야 했고 거기에 있었습니다.

개발자에게 완벽한 소스 제어 및 기타 기능을 제공하는 Git이 있었습니다. WordPress 설치에 버전 제어를 사용하면 개발자별 시스템에서 백업하는 데 더 이상 시간을 소비하지 않고 실제로 코딩에 시간을 소비하므로 개발이 즉시 가속화되고 정리되었습니다. 변경 사항이 저장되었고 마침내 "my-theme-4-v2"와 다른 세계인 내 작업에 의미 있는 메시지를 추가할 수 있었습니다.

코드베이스가 훨씬 깨끗했지만 실제 배포와 문제의 사이트가 최신 코드를 사용하고 있는지 확인하는 문제는 여전히 남아 있었습니다. 여전히 수동 FTP 업로드에 의존하여 이전 코드를 덮어쓰는 것은 기분이 좋지 않았습니다. 다른 CI/CD 서비스가 존재하는 동안, 그들 중 다수는 상당한 가격표와 많은 양의 설정을 수반했습니다. 서버 재구성, 가장 단순한 웹사이트라도 또 다른 서비스에 의존, 다른 서비스의 전체 "일을 하는 방식" 및 모든 그와 함께 오는 특이점.

이 튜토리얼과 유사한 설정은 GitHub/GitLab 및 기타 서비스에서 수행할 수 있지만 무료 개인 리포지토리(GitHub에서 최근에 제공한 것임)로 인해 초기에 Atlassian 바구니에 계란을 넣었습니다. Bitbucket이 파이프라인 및 배포 서비스를 도입했을 때 FTP를 통해 다시 업로드하거나 외부 서비스를 사용하지 않고도 새 코드를 스테이징 또는 프로덕션 사이트(또는 그 사이의 다른 사이트)에 자동으로 배포할 수 있습니다. 이제 개발자는 WordPress 개발에서 소스 제어의 모든 값을 사용할 수 있으며 추가 클릭이나 키 입력 없이 해당 변경 사항을 적절한 대상으로 즉시 보낼 수 있으며 모든 상태를 하나의 대시보드를 통해 볼 수 있습니다. 이렇게 하면 모든 것이 동기화 상태를 유지하고 각 사이트에서 실행 중인 코드를 한 눈에 정확히 알 수 있습니다. 또한 Bitbucket의 빌드 시간은 매우 저렴합니다. 한 달에 50분 무료이며 "초과 요금 무료" 플랜 옵션이 있습니다.

이 새로운 모델과 Bitbucket Pipelines 설정의 세부 사항에서 소스 제어의 분기 및 기타 기능을 가장 잘 사용하는 방법을 알아내는 데 약간의 시작 시간이 걸렸습니다. 다음은 새 WordPress 프로젝트를 시작하는 데 사용하는 프로세스입니다. git 및 WordPress 설치 설정에 대한 모든 핵심 내용을 다루지는 않겠습니다. Google 검색만으로 이에 대한 훌륭한 리소스가 제공되기 때문입니다. 결국 콘텐츠 흐름은 다음과 같습니다.

Alexa Green WordPress 배포 루틴

여기에 설명된 단계는 필요에 따라 수행해야 합니다.

클라이언트의 서버에서

라이브 사이트의 도메인(예: clientsite.com)과 준비를 위한 하위 도메인(예: staging.clientsite.com)을 설정합니다.

라이브 사이트와 스테이징 하위 도메인 모두에 WordPress를 설치합니다. 이것은 cPanel/Softaculous(클라이언트 호스팅에 이 기능이 있는 경우)를 통해 또는 wordpress.org에서 다운로드하여 수행할 수 있습니다. 라이브 및 스테이징을 위한 별도의 데이터베이스가 있는지 확인하십시오.

Bitbucket.com에서

새 저장소를 설정합니다. 시작하고 진행하려면 .README를 포함하십시오.

리포지토리에서 설정 > 파이프라인 > 설정 으로 이동한 다음 파이프라인 사용 을 선택합니다.

설정 > 파이프라인 > 리포지토리 변수 에서 다음을 입력합니다.

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password

파이프라인 > 설정 으로 돌아가서 bitbucket-pipelines.yml 구성 버튼을 클릭합니다. 다음 페이지에서 언어로 PHP 를 선택하십시오. 다음 코드와 같은 것을 사용하고 싶을 것입니다. PHP 버전을 클라이언트 서버에서 사용 중인 것으로 교체하고 URL/FTP 서버를 실제 클라이언트 사이트(프로덕션 및 스테이징) URL/FTP 서버로 교체해야 합니다.

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com

파일 커밋 을 클릭합니다. 이제 파이프라인 설정이 커밋되고 실행됩니다.

모든 것이 성공적으로 배포되면 뒤로 돌아가 bitbucket-pipelines.yml 파일을 편집합니다( 파이프라인 > 설정 및 보기 bitbucket-pipelines.yml 을 통해 얻을 수 있음). git ftp init 라고 표시된 두 위치를 git ftp push 및 save/commit으로 교체하고 싶을 것입니다. 이렇게 하면 변경된 파일만 업로드되므로 빌드 시간을 절약할 수 있습니다. 이제 bitbucket-pipelines.yml 파일이 다음과 같아야 합니다.

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com

main-dev 라는 브랜치를 추가합니다.

로컬 컴퓨터에서

로컬 설치에 사용하려는 빈 디렉토리에 리포지토리를 복제합니다. main-dev 브랜치를 확인하십시오.

이 디렉토리에 로컬 WP 설치를 설정하십시오. 이를 위한 많은 도구가 있습니다. Local by Flywheel, MAMP, Docker 등. 모든 것이 클라이언트 서버에서 실행되는 것과 동일한지(WordPress 버전, PHP 버전, Apache/Nginx 등) 확인하십시오.

다음과 같은 .gitignore 를 추가합니다. 기본적으로 Git이 wp-content를 제외한 모든 것을 무시하도록 하고 싶습니다(설치 간의 설치 문제를 방지하기 위해). 큰 백업 파일과 시스템 생성 아이콘 및 DS_Store 파일을 무시하는 고유한 규칙을 추가할 수도 있습니다.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

.gitignore 를 저장하고 커밋합니다.

변경하고 그에 따라 커밋합니다.

main-dev에 커밋할 때마다 스테이징 사이트로 FTP 업로드가 실행됩니다. 마스터에 커밋할 때마다 프로덕션 사이트로 FTP 업로드가 실행됩니다. 이것은 빌드 시간을 사용하므로 main-dev의 분기에서 대부분의 로컬 변경을 수행한 다음 하루 일과가 끝나면 main-dev에 병합할 수 있습니다.

main-dev를 마스터에 병합하면 모든 스테이징 변경 사항이 적용됩니다. Bitbucket.org의 리포지토리에서 파이프라인 및 배포 상태를 확인할 수 있습니다.

여러 설치에서 WordPress 데이터베이스 동기화

위의 항목은 파일(테마, 플러그인 등)만 동기화합니다. 프로덕션과 스테이징 간에 데이터베이스를 동기화하는 것은 다른 문제가 됩니다. 클라이언트가 스테이징 사이트에 반영되지 않은 변경 사항을 라이브 사이트에서 수행하는 경우가 많고 그 반대의 경우도 마찬가지이기 때문입니다.

WordPress 설치 간에 데이터베이스를 동기화하기 위해 몇 가지 옵션이 있습니다. 전통적으로 phpmyadmin 을 통해 가져오기/내보내기로 데이터베이스를 업데이트할 수 있습니다. 그러나 게시물 콘텐츠의 영구 링크와 같이 업데이트해야 하는 특정 항목을 업데이트할 수 없기 때문에 까다롭습니다. 이 방법을 사용할 때 즐겨 사용하는 도구는 Velvet Blues Update URL 플러그인이며, 이를 사용하여 이전 사이트 URL(예: https://staging.clientsite.com)의 인스턴스를 새 사이트 URL( 예: https://clientsite.com). 상대 경로 및 문자열과 함께 사용할 수도 있습니다. 이 방법은 결국 인적 오류의 여지가 많이 남습니다. 교체된 문자열이 잘못 작성되면 전체 사이트가 중단되고 플러그인을 사용하거나 대시보드에 액세스할 수 없게 될 수 있습니다.

All-in-One WP Migration과 같은 플러그인은 기본적으로 검색/바꾸기 기능을 제공하고 매우 사용자 친화적이지만 파일도 가져와서 전체 파이프라인 워크플로의 가치를 취소합니다. 또한 모든 wp-uploads를 다시 가져오기 때문에 엄청난 파일과 로드 시간이 발생할 수 있습니다(따라서 설치 간에 변경 사항을 이동하는 데 적합하지 않음). 이와 같은 플러그인은 보관/보안 목적으로 전체 사이트 백업용으로 가장 잘 예약되어 있습니다.

VersionPress는 흥미로운 솔루션처럼 보이지만 아직 많은 프로덕션 환경에서 입증되지 않았습니다. 현재로서는 WP Sync DB 또는 WP Migrate DB Pro와 같은 플러그인이 데이터베이스 관리에 가장 적합한 솔루션인 것 같습니다. URL과 경로를 자동으로 업데이트하는 옵션을 제공하면서 여러 설치에서 데이터베이스를 가져오거나 푸시할 수 있습니다. 사용자 및 사이트 전체 설정을 다시 가져오는 데 시간을 낭비하지 않고 게시물 콘텐츠 전용 wp_posts와 같은 특정 테이블만 마이그레이션할 수 있습니다. 저는 프로덕션 데이터를 덮어쓰지 않도록 항상 라이브에서 가져오는 것을 좋아합니다. 다음은 WP Sync DB를 사용하는 경우의 설정 예입니다(WP Sync DB github에서 더 많은 연습 사용 가능).

라이브 사이트에서: "이 저장소에서 가져오기 허용" 설정이 활성화된 WP Sync DB를 설정합니다.
스테이징 사이트에서: Pull from Live 설정으로 WP Sync DB를 설정합니다. 이름을 "라이브 투 스테이징"으로 지정합니다.
로컬 개발자 설정에서: 라이브 설정에서 끌어오기를 사용하여 WP 동기화 DB를 설정합니다. 이름을 "live-to-dev"로 지정합니다.

또한 "dev-to-staging" 푸시 규칙을 설정하고 데이터베이스를 덮어쓸 수 있도록 스테이징 사이트 설정을 확인해야 할 수도 있습니다.

마무리

나는 이러한 방법이 새로운 WordPress 웹사이트를 개발하고 이미 존재하는 사이트를 재설계/재구성하는 대부분의 사용 사례에서 작동하는 경향이 있다는 것을 발견했습니다.

추가된 개발 시간/노력과 사이트 간 작업을 위한 의도적이고 안전한 데이터베이스 마이그레이션 논리 없이 모든 사이트 버전을 최신 상태로 유지하는 코드 배포가 가능합니다. 플러그인 업데이트는 소스 제어 내에서도 수행되므로 라이브 사이트에 커밋하기 전에 스테이징에서 플러그인 업데이트를 안전하게 확인할 수 있으므로 프로덕션 사이트 중단을 최소화할 수 있습니다.

데이터베이스 관리에 소스 제어 워크플로를 더 많이 가져오기 위한 개선의 여지가 분명히 있지만 프로덕션 환경에서 VersionPress와 같은 도구가 더 많이 사용되기 전까지는 WP Sync DB 또는 WP Migrate DB Pro를 통해 데이터베이스를 선택적으로 끌어오기/푸시하는 이 방법이 적합해 보입니다. 이를 처리하는 가장 안전한 방법입니다. WordPress 워크플로에 적합한 것이 무엇인지 또는 이 모든 후에 올가미를 잡고 카우보이 코딩을 하고 싶은지 궁금합니다!