파일별로 수동으로 프로젝트를 서버 파일에 배포하는 것이 가장 좋은 방법입니까?

26

내가 현재 일하는 회사는 아직 지속적인 전달을 구현하지 않습니다. 우리는 여전히 파일 단위로 서버에 프로젝트를 수동으로 배포합니다. 각 배포마다 하나의 프로젝트 아티팩트를 수동으로 배포하거나 파일 별 배포를 계속 수행하는 것이 가장 좋은 방법은 무엇입니까?

deployment server devops

— 제이크 ull 러
소스

12

이 작업에는 원격으로 "모든 상황에 대한 한 가지 실천"이 없습니다.

— Whatsisname

26

일반적으로 나는 “모범 사례”에 대한 질문을하는 것이 나쁜 이유에 링크합니다 . 나는 이것이 최악의 방법 이라는 데 모두 동의 할 수 있다고 생각 합니다. "서버에 대한 설정 불"보다 약간 높습니다.

3

관련 : en.wikipedia.org/wiki/…

— Jens Schauder

9

OP가 이미 답을 알고 있기 때문에 OP가이 질문을하고있는 것으로 의심되며 그의 직장은 Doing It Wrong (tm)이며 OP는 작업 방식을 바꾸는 증거를 얻기 위해 노력하고 있습니다.

— user1936

2

우리는 2 천년 안에 이런 식으로 했어요. 괜찮을거야! ;)

— Don Branson

103

가장 좋은 방법은 무엇입니까? 각 배치마다 하나의 프로젝트 아티팩트를 수동으로 배치하거나 파일 배치별로 파일을 계속 수행합니까?

둘 다.

모범 사례는 배포를 완전하고 독점적 으로 자동화하는 것입니다. 즉, 아무도 서버에 수동으로 아무것도 넣지 않습니다.

"요약의 요약을 요약하려면 : 사람들은 문제입니다." (더글러스 애덤스)

사람들은 실수를합니다. 복사 를 잊어 버린 파일 중 하나 가 광범위하게 변경된 공유 "라이브러리"인 경우 전체 프로덕션 사이트가 중단 될 수 있습니다.

— 필 W.
소스

17

@JohnHamilton 컴파일 자동화가 어려운 작업이라면 장기적으로 해결해야 할 문제입니다. 완전히 자동화 된 배포로 완성 된 개발, 테스트, 사전 프로덕션 환경이 필요하지는 않지만 표준 배포 패키지를 만드는 것이 표준 관례입니다.

— Neil

20

어, 회사의 규모는 실제로 어느 정도 문제가 아닙니다. 비용은 배포가 자동화되는 정도와 생산 환경의 복잡성과 관련이 있습니다. 그러나 스크립트와 같은 간단한 것부터 시작하여 생산물에 빌드 출력을 복사하고 (즉시 실질적인 비용 절감을 통한 소규모 투자), 그로부터 증가하는 자동화 및 "비용"(시간 / 돈)의 기울기가 있습니다. 회사 규모보다 경영 구매에 대해.

— BurnsBA

39

@JohnHamilton : 제대로 관리되지 않은 소규모 회사는 스스로 그렇게 생각할 수 있습니다. 파일 복사를 자동화하는 것은 어려운 작업이 아니며, 고용 된 사람이이 작업을 정기적으로 수행하는 데 드는 비용이 가장 사소한 스크립트를 작성하는 것보다 훨씬 비용이 많이 듭니다.

— GManNickG

8

@JohnHamilton : 자동화 비용은 수동 배포 중 실수로 인한 위험에 대비해야합니다.

— Robert Harvey

7

Jenkins가 반드시 필요한 것은 아닙니다. 많은 scp 명령 (또는 수동으로 업로드 할 때 사용하는 것)이있는 체크인 된 스크립트 만 개선됩니다.

— user253751

14

수동 단계는 많은 노력을 기울이고 위험합니다. 필요한 파일을 잊어 버릴 수 있습니다. 팀의 모든 사람이 어떤 파일을 복사해야하는지 알지 못할 수도 있습니다. 이러한 모든 문제로 인해 배포가 크고, 까다 롭고, 드물게 – 불필요하게 이루어집니다. 자동화는 이러한 문제를 해결합니다.

배포가 간단 해지기 때문에 가장 간단한 자동화 단계조차도 큰 이점을 얻을 수 있습니다. (S) FTP 또는 Rsync 또는 다른 기술을 통해 파일 또는 아티팩트를 복사하는 스크립트는 훌륭한 첫 단계입니다. 나중에 해당 스크립트를 확장하여 서비스 다시 시작과 같이 서버에서 배포 전 및 배포 후 단계를 자동으로 수행 할 수 있습니다.

— 아몬
소스

총 서버 수가 2 이하인 경우 수동은 자동보다 덜 위험합니다. 자동에는 광범위한 버그 검사가 필요합니다. 나는 사소한 자동 솔루션을 본 적이 없다.

— Joshua

3

@Joshua 나는 서버의 수가 여기에 요소가되어야하는지 확신하지 못한다. 자동화는 또한 동일한 서버에 여러 번 배포 할 때 가치가 있습니다. 문제는 누가 더 많은 것을 신뢰 하는가하는 것입니다. 컴퓨터는 한 번 작동 한 스크립트를 충실하게 실행하거나 매번 필요한 모든 단계를 기억할 수 있습니까? 망각하고 잊을 수없는 인간으로서, 나는 수동으로 일을하지 않는 것을 선호합니다. 때로는 일회성 작업을 스크립트로 작성하여 명령을 실행하기 전에 검토 할 수도 있습니다. 작동 할 때까지 임의의 작업을 수동으로 수행하는 것보다 훨씬 덜 위험합니다!

— amon

나는 두 가지 방법으로 광범위한 경험을 가지고 있습니다. 수동 배포를 위해 만드는 것은 xcopy 설치이므로 실제로 일부를 잊어 버릴 단계가 없습니다.

— Joshua

9

모범 사례는 일종의 자동화 된 프로세스를 구현하는 것입니다.

고려해야 할 '파일 별'접근 방식에 특별한 이유가 없는지주의하십시오.

— 이완
소스

1

나는 이것이 세계에서 완전히 모범 사례가 아닌지 확인하고 싶기 때문에이 질문을합니다. 여전히 앱 / 프로젝트를 수동으로 배포하는 회사 / 개발자가 여전히 있으며, 개발 할 때마다 파일 배포로 파일을 악화시키는 것이 궁금합니다.

— Jake Muller

4

가장 좋은 질문은 "우리는 왜 이런 식으로 하는가?"입니다. 이유를 생각할 수는 없지만 일부 회사는 트리거를 수동으로 유지하는 것을 좋아합니다.

— Ewan

8

@JakeMuller이 답변의 라인 사이에서 읽어야 할 것은 상황에 대한 추론을 통해 결정을 내려야한다는 것입니다.

— Blrfl

파일 별 파일 접근 방식의 이유는 파일 간의 종속성이므로 파일 업데이트는 해당 파일에 종속 된 다른 파일을 변경하기 전에 배포되기 때문입니다. 잘못된 순서로 파일을 업데이트하면 시스템이 잠깐 동안 제동 될 수 있습니다.

— bdsl

6

Continuous Delivery (또는 실제로 배포)를 사용하고 각 파일을 직접 이동하면 두 가지 극단을보고 있습니다. 완전 자동화 된 파이프 라인 (아직)을 만들거나 할 수 없다는 것을 완벽하게 이해할 수 있습니다. 그러나 프로세스의 일부 자동화를 고려해야합니다.

각 파일을 직접 이동하는 것은 매우 위험하므로 예를 들어 코드 리포지토리 태그 지정, 컴퓨터에서 해당 태그 확인, 아티팩트 빌드 및 서버에 업로드 등의 방법으로 해당 위험을 완화 할 수 있습니다. 이러한 각 단계를 자동화하여 마우스 클릭 몇 번으로 실행할 수 있으므로 파일을 잊어 버리거나 실수로 추가 파일을 생성 할 위험이 크게 줄어 듭니다.

한 번에 한 단계 씩 가능한 것을 자동화하십시오. 완전 자동화 된 CD 파이프 라인을 감당할 수 없다고해서 일부 부품을 자동화하지 않아도됩니다.

— 블루 리버
소스

1

모범 사례는 특정 회사의 특정 배포에 대한 비용 / 이익 분석을 수행하는 것입니다.

일반적인 대답은 "수동으로 작업하지 말고 자동화하십시오"입니다. 이것은 일반적으로 일반적인 종류의 회사에 대한 정답입니다. 귀하가 받고있는 답변의 통일성은 커뮤니티가이를 모범 사례로 얼마나 강력하게 찾는지를 나타내는 것이어야합니다. 회사에서 자동화가 올바른 도구가 아니라고 생각하는 경우 자동화를 독창적으로 만드는 요소를 이해해야합니다. 이러한 독창성은 의사 결정 과정에 반영되어야합니다. 샘플 세트가 1 인 경우 "모범 사례"가 없습니다.

"파일 수"및 "업데이트 빈도"및 "문제의 결과는 무엇입니까"및 "나쁜 변경을 얼마나 빨리 롤백 할 수 있습니까"와 같은 질문은 대답해야 할 중요한 질문입니다. 자동화하는 경우 이러한 많은 질문이 중요하지 않지만 수동 업데이트 프로세스에 대한 비용과 이점을 올바르게 할당하는 데 필수적입니다.

— 콜트 암몬-복원 모니카
소스

1

수동 파일 별 복사와 연속 전송 사이에는 많은 회색 음영이 있습니다.

예를 들어 zip 파일, rpm 스타일 패키징, 코드 관리 도구 (예 : 꼭두각시 또는 요리사) 등의 인프라 또는 간단한 스크립트를 사용하여 배포 프로세스의 복잡성을 줄이십시오. ftp 서버의 스테이징 영역.

더 많은 수동 단계가있는 배포 프로세스는 오류가있을 가능성이 높으며 다른 사람들이 말했듯이 인적 요소를 제거합니다.

완전한 연속 제공 (비용이 많이 들고 시간이 지남에 따라 노력 / 투자 / 혁신)을 구현할 필요가 없습니다. 간단하게 시작하고, 효과를 발휘하고, 이점을 입증하고, 거기서 시작하십시오.

— 바이킹 스티브
소스

0

사용중인 소프트웨어 기술 (또는 스택), 해석 된 언어, 컴파일 된 언어, 데스크톱 앱, 모바일 등 소프트에 따라 다릅니다. dev. 부서 정책, 자동화 할 도구가있는 경우 앱의 중요성과 고려해야 할 중요한 사항 중 하나는 소프트웨어 아키텍처 (앱 디자인 방식)입니다. 그렇기 때문에 여기에 다른 답변이 있습니다. 경험상, 최선의 방법은 실수를 피하기 위해 배포 작업에서 가능한 사람의 개입을 줄이는 것입니다. 배포 전에 QA 서버 (예산이 문제인 경우 가상 서버 사용)의 모든 사항을 테스트하고 재해 발생시 이전 버전으로 복원하기위한 역 절차를 수행하는 것이 좋습니다 ( 항상 백업이 있음).

— 에두 가르시아
소스