나는 새소리를 배우기 시작했고 webpack을 사용하여 내 프로젝트를위한 더 나은 개발 워크 플로우를 시작했습니다. (대부분의 경우 나는 워드 프레스 테마를 개발했습니다). 개발 단계에서는 webpack과 함께 gulp를 사용하여 js 파일을 묶고 sass를 컴파일합니다.웹 배포를위한 모범 사례
개발 프로세스가 끝난 후 모든 내용을 내 FTP로 업로드 한 다음 문제가 시작됩니다 ... 일부 스타일이 변경되면 컴파일 된 CSS 파일에서 직접 새 스타일을 작성하고 추가 자바 스크립트가 필요한 경우에는 축소 된 파일로 작성합니다 , bundlelet javascript-file 그리고 나는 이것이 정말로 나쁘다고 생각한다.
그래서 프로덕션 환경에서 서버의 변경 사항 (스타일, 애드온 js 코드)을 처리하는 가장 좋은 방법은 무엇입니까? (제 서버에 노드가 없습니다)
글쎄. 우선 가장 먼저해야 할 일 : 이것이 나쁜 습관이라는 것이 맞습니다. 번들 된 프로덕션 파일에 직접 변경 사항을 기록하지 마십시오. 개발 환경은 항상 최신 버전의 코드를 나타내야합니다. 그런 다음 번들로 묶어 생산에 적용하십시오.
첫 번째 단계는 개발 환경에서 로컬로 변경 한 다음 파일을 번들로 만든 다음 프로덕션 서버로 푸시하여 이전 파일을 대체하는 것입니다.
나는 또한 당신이 그런 예를 들어 가을 개발 유지 수를 자식, 그리고 코드의 마스터 지점으로, 버전 관리 도구의 일종을 사용하는 것이 좋습니다 것입니다. Develop은 다음 버전에서 작업하는 곳이며, master는 프로덕션 환경을 현지에서 표현한 것입니다.
배포 프로세스는 모두 프로덕션 환경과 사용자가 가지고있는 제어 권한에 따라 다릅니다. 나는 FTP를 사용하여 새 파일을 보내지 않는 것이 나쁜 습관으로 간주 될 것이라고 생각하지 않는다. 대부분의 개발자는 아마도 프로세스를 자동화하는 일종의 배포 스크립트를 선호 할 것입니다. 프런트 엔드 코드의 경우 일반적으로 scp을 사용하여 변경 내용을 제작에 적용하는 셸 스크립트를 사용합니다. 하지만 이는 가능한 많은 솔루션 중 하나 일뿐입니다.
상황 (Wordpress + CSS를 변경해야 함)을 고려할 때 좋은 임시 해결책은 맞춤 CSS 기능을 사용하는 것입니다. 이전에는 플러그인을 사용 했었지만 최근 버전의 WordPress에는 내부에 플러그인이 포함되어 있다고 생각합니다.
그런 다음 일부 Wordpress 양식에 CSS를 삽입하면 페이지에 추가됩니다. 이렇게하면 축소 된 파일을 손상시키지 않고 변경 사항을 추출하여 개발 환경에 되돌릴 수 있습니다.