Deploybot으로 라이브 배포 및 스테이징
게시 됨: 2022-06-30한동안 웹 개발에 종사했다면 사이트를 업데이트하려고 할 때 파일 전송을 망쳤을 것입니다. 최상의 시나리오에서는 쉽게 식별할 수 있는 여러 파일을 디렉터리에 추가하고 오류를 수정하기 위해 제거합니다. 예, 시간이 많이 걸리고 성가시지만 해를 끼치 지 않습니다.
최악의 시나리오에서는 많은 테마 파일을 부적절하게 전송합니다. 그런 다음 덮어쓴 항목과 전혀 속하지 않은 항목, 그리고 테마의 적절한 작동 상태를 어떻게 복구할 수 있는지 파악해야 합니다.
오늘은 Git 및 Deploybot을 사용하여 배포 프로세스를 자동화하여 이 문제를 해결하는 방법을 알아보겠습니다.
자동 배포란 무엇입니까?
기본 자동 배포에는 이 다이어그램과 같이 네 부분이 있습니다.
대부분의 개발자는 코드와 서버만으로 시작합니다. 그들은 사이트의 작업 복사본을 변경한 다음 FTP를 통해 해당 변경 사항을 서버에 직접 푸시합니다. Coda 또는 Dreamweaver와 같은 도구에는 직접 FTP 통합이 있으므로 코딩 환경 내에서 이를 수행할 수 있습니다.
많은 개발자가 취하는 다음 단계는 라이브 서버를 직접 수정하지 않도록 스테이징 사이트를 추가하는 것입니다. VVV 또는 MAMP와 같은 것으로 이 작업을 수행할 수 있습니다. 이는 종종 Git과 같은 버전 제어 시스템을 사용하여 로컬 작업 사이트에 대한 변경 사항을 관리한다는 의미이기도 합니다.
준비 사이트를 추가하면 복잡성도 추가됩니다. 로컬 작업 사이트에서 클라이언트가 변경 사항을 볼 수 있는 스테이징 사이트로 코드 변경 사항을 가져오는 방법은 무엇입니까? 예, 이미 말했듯이 FileZilla, Transmit 또는 Forklift와 같은 기본 FTP 클라이언트를 사용하여 변경할 때 파일을 이동할 수 있지만 이는 오류가 발생하기 쉽고 배포 프로세스를 자동화하면 많은 시간을 절약할 수 있습니다.
변경한 파일을 스테이징 서버로 푸시하는 대신 다른 시스템을 사용하여 Git 리포지토리의 변경 사항을 자동으로 감지하고 클라이언트가 작업을 확인하는 데 사용할 수 있는 스테이징 사이트로 변경 사항만 푸시합니다.
그래도 라이브 사이트는 수동 배포로 남게 되며 라이브 작업 사이트를 중단하면 실제 비용 손실을 의미할 수 있기 때문에 훨씬 더 무섭습니다. 대신 스테이징에 자동으로 배포하도록 배포 시스템을 설정하고 준비가 되면 클릭 한 번으로 시스템이 라이브 환경에 배포된다고 가정해 보겠습니다.
이제 다음과 같은 시스템이 생겼습니다.
함께 작업하는 모든 클라이언트에 대해 이 배포 프로세스를 설정하는 방법을 보여 드리겠습니다. 이것은 내가 새로운 프로젝트를 시작하자마자 취하는 단계입니다. 클라이언트 프로젝트에서 다른 작업을 시작하기 전에 항상 배포 프로세스가 설정되어 작동하는지 확인합니다.
Git 리포지토리를 구성하는 방법
첫 번째 선택은 자동화된 배포를 설정할 디렉터리는 무엇입니까? 내 클라이언트가 WordPress 설치에 대한 전체 소스 제어를 특별히 요청하지 않는 한 wp-content 디렉토리를 사용하여 자동화된 배포 시스템을 설정합니다. git 저장소를 초기화하는 이 명령을 실행하여 터미널에서 시작합니다.
자식 초기화
이제 항상 배포하고 싶지 않은 파일을 무시할 때입니다. 백업 파일, 이미지 및 많은 코드 편집기가 디렉토리에 추가하는 사용자 정의 프로젝트 파일과 같은 파일입니다. 아래에서 일반적인 .gitignore 파일을 볼 수 있습니다.
config/app_config.yml
구성/데이터베이스.yml
설정/*.sphinx.conf
구성/s3_credentials.yml
*~
*.은닉처
*.통나무
*.pid
tmp/**/*
.DS_스토어
db/cstore/**
DB/스핑크스/**
문서/API
문서/앱
문서/플러그인
문서/*.dot
적용 범위/*
db/*.sqlite3
*.tmproj
*.sw?
*.esproj
_메모*
dwsync.xml
팟캐스트.xml
*.kpf
*업로드/*
*.swp
*.아이디어
*.숭고한 프로젝트
*.sublime-작업 공간
*/노드 모듈/*
태그
*.박
은닉처/*
관리wp/*
뮤 플러그인/*
dp.php
상승 기류/*
언어/*
db.php
플러그인/wp-rocket/cache.json
필요에 따라 자유롭게 추가하거나 제거하십시오. 내가 작업하는 거의 모든 프로젝트에는 스테이징 및 라이브 사이트에 덮어쓰고 싶지 않은 자체 사용자 지정 파일이 있는 로컬 작업 사이트에 특정한 일부 파일을 무시하기 위해 일종의 사용자 지정 항목이 필요합니다.
여기에서 배포 시스템을 시작하는 데 필요한 분기를 설정할 시간입니다. 나는 두 가지 주요 지점을 사용합니다. 먼저 내 라이브 프로덕션 사이트에 해당하는 마스터 브랜치입니다. 두 번째는 스테이징이라는 레이블이 붙은 분기이며 클라이언트가 변경 사항을 확인하는 방법으로 사용하기를 원하는 스테이징 사이트에 해당합니다.
Git 리포지토리를 초기화할 때 이미 마스터 브랜치가 있으므로 이 명령을 사용하여 스테이징 브랜치를 추가하고 확인하십시오.
git checkout -b 스테이징
이 명령은 새 분기를 만들고 체크아웃합니다. git을 처음 사용하는 경우 Git 설명서에서 사용 가능한 명령에 대한 자세한 정보를 찾을 수 있습니다.
이제 프로젝트를 소스 제어 시스템으로 푸시해야 합니다. Github와 Bitbucket은 우리가 Deploybot이라고 하는 자동화된 배포 시스템과 함께 작동하는 두 가지 인기 있는 선택입니다. 두 사이트 중 하나를 사용하여 새 리포지토리를 만들면 Github 또는 Bitbucket의 온라인 버전에 로컬 리포지토리를 추가하기 위한 추가 지침이 제공됩니다.
- Bitbucket 저장소 설정 문서
- Github 저장소 설정 문서
Deploybot 설정
내가 개발자로서 처음으로 더 복잡한 작업을 시작할 때 수동 FTP 배포를 엉망으로 만드는 것에 대해 온라인에서 불평했을 때 친구 Duane은 계속 Deploybot을 추천했습니다. 내가 말한 것을 마침내 수행하기까지 여러 권장 사항이 필요했지만 지금은 몇 년 동안 행복한 Deploybot 고객이었습니다.
사이트를 배포하는 다른 방법이 있지만 대부분은 코드 편집기를 통해 Git Webhook 또는 일부 자동화된 배포 구성 파일과의 인터페이스를 포함합니다. 이러한 다른 도구에는 많은 기능이 있지만 자동화된 배포를 막 시작하는 경우 Deploybot과 같은 간단한 작업을 시작하는 것이 좋습니다.
시작하려면 Deploybot 계정에 가입하고 계정에 Github 또는 Bitbucket을 연결하십시오. 오늘은 기존 Bitbucket 계정을 사용하겠습니다. 먼저 Deploybot 계정에 새 리포지토리를 추가합니다.
자동 배포를 위해 설정하려는 리포지토리를 찾았으면 페이지 하단에 있는 연결이라고 표시된 버튼을 클릭합니다. 그러면 Deploybot이 리포지토리 초기화를 완료하는 동안 리포지토리 페이지로 돌아갑니다. 일반적으로 이 작업은 1~2분 안에 완료되므로 커피를 채우고 다시 돌아와 배포 프로세스 설정을 완료합니다.
저장소가 설정되면 해당 저장소를 클릭하여 기본 페이지로 이동합니다. 아직 sFTP 정보가 설정되어 있지 않기 때문에 서버를 설정하라는 큰 상자가 표시됩니다. 버튼을 클릭하면 환경과 서버를 생성할 수 있습니다.
스테이징 환경에 배포를 시작하겠습니다. 따라서 서버에 스테이징으로 레이블을 지정하십시오. 자동 배포를 선택하고 분기를 스테이징으로 설정했는지 확인합니다.
완료되면 페이지 하단의 저장 버튼을 클릭하여 서버 구성으로 이동합니다.
다음 페이지에서 다시 스테이징 서버로 레이블을 지정하고 사이트의 sFTP 정보를 입력합니다. 어디서 찾을 수 있는지 잘 모르겠다면 이 유용한 가이드를 읽어보세요.
sFTP 정보를 입력하면 맨 아래로 스크롤하여 저장할 수 있습니다. 그런 다음 Deploybot은 연결을 테스트하여 제공한 정보가 작동하는지 확인합니다. 이제 사이트에 대한 초기 배포를 수행하여 모든 것이 작동하는지 확인할 차례입니다. 배포가 제대로 작동하는지 쉽게 확인할 수 있는 방법으로 test.txt 파일을 배포에 추가하는 경우가 많습니다.
환경 기록에 배포를 시작하고 배포를 클릭합니다.
이제 이 배포 옆에 있는 Deploybot 내부에서 볼 수 있는 메모로 마지막 git 커밋 메시지가 있는 페이지가 표시됩니다. 큰 변경 사항에 대해서는 이것을 변경할 것이지만 CSS나 사소한 변경 사항이 있는 경우 커밋 메시지가 남을 수 있습니다. 이것은 스테이징이므로 스테이징 분기에 대한 모든 단일 커밋이 자동으로 배포됩니다. 즉, 커밋 메시지가 표시됩니다. 스테이징 사이트에 수동으로 수행해야 하는 것은 초기 커밋뿐입니다.
이제 파일이 스테이징 사이트에 게시되었는지 확인하고 라이브 배포를 설정할 수 있습니다.
라이브 배포의 경우 자동 배포를 선택 하지 않고 마스터 분기를 배포 소스로 선택했는지 확인합니다. 라이브 사이트에 변경 사항을 푸시할 준비가 되었을 때 이것이 수동 배포가 되기를 원합니다.
이렇게 하려면 마스터 브랜치를 체크아웃한 다음 스테이징 브랜치의 변경 사항을 마스터로 병합해야 합니다.
이 명령으로 할 수 있습니다.
자식 체크 아웃 마스터
자식 병합 스테이징
git push 오리진 마스터
이제 Deploybot 계정으로 이동하면 스테이징 환경에 대한 초기 배포와 마찬가지로 변경 사항을 수동으로 배포할 수 있습니다. 라이브 환경의 경우 라이브 사이트에 푸시되는 변경 사항에 맞게 배포 메시지를 변경해야 합니다. 또한 사이트의 백업을 만들어야 합니다. 사이트의 백업 탐색에 액세스한 다음 수동 백업을 생성하여 이를 수행할 수 있습니다.
스테이징 및 라이브 환경 모두에 대한 자동화된 배포 시스템 설정이 완료되었습니다.
기타 배포 고려 사항
이 시스템은 대부분의 개발자에게 큰 발전이지만 문제가 없는 것은 아닙니다. 가장 큰 것은 변경 사항이 많은 경우 FTP가 변경된 파일 전송을 완료하기를 여전히 기다리고 있다는 것입니다. 이것은 누군가가 귀하의 사이트를 방문했지만 귀하의 사이트에서 실행하는 데 필요한 모든 파일이 존재하지 않는다는 것을 의미할 수 있습니다.
많은 클라이언트의 경우 이는 문제가 되지 않지만 사이트를 위한 것이라면 Atomic 배포 시스템 설정을 살펴봐야 합니다. 이러한 유형의 배포 시스템은 모든 파일을 이동하고 제대로 작동하는지 확인한 다음 서버의 파일 설정을 변경하여 이제 새 디렉토리가 사이트를 실행하는 디렉토리가 되도록 합니다.
새 폴더에 연결하는 과정은 컴퓨터만 알아차릴 정도로 짧은 시간이 걸립니다. 이는 또한 나중에 문제를 발견한 경우 시스템 링크를 사이트의 이전 버전으로 다시 변경하여 작동하던 버전으로 롤백할 수 있음을 의미합니다. 이것은 매우 짧은 시간만 소요되며 가동 중지 시간을 줄입니다.
무엇을 선택하든 오늘 FTP 클라이언트를 사용하여 클라이언트 파일을 배포하는 것을 중단하십시오. 파일 배포를 실수 하지 않을 때마다 Deploybot의 작은 월별 비용이 복구됩니다.