확실하지 않습니다.이 시나리오가 발생하는 사용자가있는 경우 작은 규모의 프로젝트가 있거나 매일 개의 LIVE 라이브에 푸시해야하는 수정 사항이 있습니다.전체 배포 대 일정 없음 배포
"깔끔한 빌드 및 배포 된 서버에서 배포"라는 팀이 있습니다. 다른 집합은 전체 배포를 수행 할 필요가 없다고 말하면서 dll drop 또는 aspx drop을 수행합니다.
그들은 각 방법에 대해 찬반 양론을 적었습니다. 그러나 어떤 방법을 알고 싶다면 일반적으로 각 방법에 대한 주요 후진을 따라야합니다.
내가 제어 할 수있는 사이트의 경우, 개정 제어를 위해 SVN 또는 Git을 사용하고 필요한 경우 원본을 업데이트하고 서버에서 직접 컴파일합니다. 이는 공개 된 내용의 무결성을 보장하는 것으로, "깔끔한 빌드를 수행하고 유능한 서버에 배포"팀이 제시하는 논쟁입니다. 내 통제하에 있지 않은 서버의 경우, 나는 무엇이든 할 수 있습니다.
우선 가능한 한 자동화하려고 시도함으로써 새로운 릴리스 구축 비용을 최소화하려고합니다. (더 쉽게 말하기는 쉽지만 일반적으로 시간과 돈을 잘 투자합니다. 특히 당신이 자주 출시하는 경우는 더욱 그렇습니다.)
새로운 이진 파일을 삭제할 때 큰 문제는 종종 수동 프로세스이며, easies 작업을 계속 엉망으로 만드는 경향이있는 인간에 의해 수행됩니다.
변경 사항을 제어 된 방식으로 배포하고 수동 작업을 제거하는 데 도움이되는 "패치 관리 시스템"을 정말로 찾고 있지 않습니까?
그런 식으로 패치를 버전 관리하고 잘하면 신중하게 테스트해야하기 때문에 여전히 훌륭한 무결성을 유지할 수 있습니다. 그러나 그것들은 개발되고 배포 될 수 있습니다.
무결성에 관한 것만이 아닙니다. 또한 MSI 테스트 MSI 구축을 구축하는 데 드는 인건비가 필요하거나 작동하는지 확인해야합니다. 그래서 두 번째 요점은 "비용" –
또한, 내가 무엇을 말하든 나는하지 않을 것이다. 나는 최선의 해결책이 무엇인지를 제안하고 그들이 가지고있는 것이 최적화되지 않는다면 그것을 바꿀 것이다. tho에 답해 주셔서 고맙습니다. –
두 번째 의견은 일반적으로 그들이 고용하는 500 대 정도의 제 3 자 개발 회사 중 하나의 분위기에서 배포 프로세스를 수정하지 않을 매우 큰 클라이언트에서 작동합니다. 그러나 나는 당신의 능력을 부러워합니다. – RedFilter