여러 환경이있는 좋은 이유

내 경력을 통해 나는 다른 목적을 위해 다른 환경을 가진 회사에서 일했습니다. 우리는 항상 데스크탑 환경, 테스트 환경, QA 환경, 준비 환경 및 프로덕션 환경을 가지고있었습니다. 이것은 서버 / 애플리케이션과 우리가 사용하고있는 모든 데이터 소스에 적용되었습니다.

현재 회사에서 시작했을 때 앱의 90 %가 프로덕션 데이터 소스를 바탕으로 데스크톱 환경에서 개발되었거나 플랫폼에 따라 프로덕션 서버에서 직접 개발 된 것으로 나타났습니다. 개발 팀의 기능을 향상시키기 위해 부분적으로 고용되어 인터뷰 과정에서 분명해 졌기 때문에 이것은 놀라운 일이 아닙니다. 우리는 서서히 철학을 바꾸기 시작했으며 곧 곧 대부분의 앱이 데스크톱, 테스트 또는 프로덕션 환경에서 실행될 수 있습니다. 그 준비가 끝나고 얼마 지나지 않아.

이제 대부분의 개발자는이 방법론의 이점을보고이를 신중하게 방어합니다. 그러나 이전 된 적이없는 수많은 레거시 앱이 있습니다. 우리는 이것을 시간 낭비라고 생각하는 많은 레거시 프로그래머도 있습니다. 불행하게도, 우리는 입술 서비스를 받았지만 경영진의 완전한 바이 인은 없었습니다. 우리는 약 1 년 전에 이것에 실질적으로 투자하겠다는 결심을 가지고 있었지만 상당한 계획에도 불구하고 실현 된 것은 없습니다. 이제 우리는 점점 더 많은 환경이 필요하다는 것을 알게되었습니다. 설정을 위해 서버 / 네트워크 관리 팀의 도움이 필요하며 릴리스주기를 지원하려면 비즈니스 이해 관계자의 참여가 필요합니다. 우리는 이제 합리적인 개발자들이 "정상적으로"고려할 수있는 기능을 프로젝트가 수행 할 수있는 곳에

나는 완전한 논증을 제시하고 싶지만, 중요한 문제가 생길 때까지 경영진은 시간과 관심이 없습니다. 나는 항상 그것이 단지 제 2의 본성 인 것처럼 단순히 혜택을 분명히 말할 수는 없습니다. 개발 경험이 부족한 관리자가이 아이디어를 뒷받침 할 수있는 환경을 분리해야하는 좋고 간단하며 반박 할만한 이유 가 있는지 궁금합니다 . . 주제에 관한 좋은 자료 / 문학이 있습니까?

답 : 돈

나는 실제 이유가 무엇인지 상관하지 않습니다. 특히 경영진을 다룰 때 돈은 모든 추론의 근본 원인이어야합니다.

둘 다 2 시간 동안 방에 앉아 있다면 여러 환경을 갖는 것이 더 좋은 이유 는 수십 가지 가 될 수 있습니다.

여기에 문제가 있습니다. 이유가 돈을 바탕으로하지 않는다면 아무 것도 중요하지 않습니다 .

프로그래머는 영리하지 않습니다. 그들은 창조적으로 고용되지 않았습니다. 그들은 돈을 벌거나 돈을 절약하여 수입 을 늘리기 위해 고용되었습니다 . 이 중 하나를 수행하지 않으면 이력서를 함께 사용하는 것이 좋습니다.

그 관점에서 볼 때 대답은 간단합니다.

하나의 환경 만 있으면 가동 중지 시간이 늘어나고 매출 손실이 발생합니다. 여러 환경을 통해 사용자는 회사만큼 신뢰할 수 있고 신뢰할 수있는 프런트 엔드를 제공하여 수익을 보호 할 수 있습니다.

매일 반복하십시오.

아래 에이 답변에 실제 가치를 더하는 몇 가지 훌륭한 의견이 있으므로 언급하겠습니다.

• Karl Bielefeldt는 비용 / 혜택 분석이 중요한 요소라고 언급했을 때 큰 지적을했습니다. 경제학자는이를 여러 환경을 추구하는 기회 비용이라고 할 수 있습니다. 듣는 것이 놀랍지 만 여러 환경이 답이 아닌 시나리오가 있습니다! 회사의 웹 사이트가 아주 작은 추가 기능인 경우 예기치 않은 다운 타임이 실제로 비즈니스를 수행하는 데있어 가장 비용 효율적인 방법 일 수 있습니다. 이것은 당신이있는 위치처럼 들리지 않지만 언급 할 가치가 있습니다.

• BlairHippo는 재앙처럼 보이게해야한다는 점에서 좋은 점이있었습니다 (데이터를 잃어버린 경우에도 마찬가지입니다). 책임은 관리자를 설득하기위한 훌륭한 도구이지만 여전히 같은 이유로 소송이 비싸다. 그것들을 피하면 돈이 절약됩니다.

부록으로, 나는 이 기사 가 꽤 좋다는 것을 알았습니다 . 귀하의 질문에 직접 대답하지는 않지만 프로그래머가 경영진에게 어떻게 보이는지 인식 할 수있게하여 결과적으로이 답변으로 이어집니다. 잘 읽었습니다.

단일 실패 지점

개발 또는 준비 환경이 없기 때문에 이러한 레거시 응용 프로그램에 대한 단일 실패 지점이 있습니다. 이러한 용어로 레거시 응용 프로그램을 설명하면 경영진이 귀하를 듣게됩니다.

메시지를 이해할 수있는 사운드 바이트로 메시지를 표시 할 수 있어야합니다. 토론 에서 " 프로그래머 말하기 "를 꺼내고 " 관리자 말하기 "로 바꾸 십시오 . 또한 포인트를 얻기 위해 엘리베이터를 30 초 동안 타고 가십시오.

상사가 보병 해병 인 상황이있었습니다. 생산성을 높이려면 해병대를위한 소프트웨어 도구와 컴퓨터 교육이 필요하다고 계속 말했습니다. 그는 그것을 얻지 못했습니다. 나는 마침내 어느 날 그의 사무실로 들어가서 일이 끝났다고 말했습니다.

"전쟁과 싸우면 지팡이, 바위, 나뭇 가지를 사용할 것입니다. 수류탄, 바주카포 및 기관총이 필요합니다." 그는 메시지를 받았습니다.

실제로 중요합니까?

별도의 환경을 사용하려는 욕구를 이해할 수 있습니다. 명백한 질문은 다음과 같습니다.

레거시 시스템 을 마이그레이션하는 것이 실제로 중요 합니까?

나는 기술적으로 가장 마음에 드는 사람들이 학계에서 어떤 방법이 더 나은지에 대한 학문적 질문에 집중하는 경향이 있다고 생각합니다. 사업 상 최고가 항상 승리하는 것은 아닙니다. 나는 이것이 부정적이라고 말하거나 화염 전쟁을 시작하지 않습니다. 나는 몇 년 동안 소프트웨어 사업 에 종사 해온 사람들에게 분명하거나 분명한 것을 진술하고 있습니다 .

모든 사업 결정은 일반적으로 인식 된 비용 / 혜택을 바탕으로 이루어집니다. 따라서 비즈니스가 묻는 질문은 다음과 같습니다.

레거시 애플리케이션에 대한 추가 시스템 및 개발 투자 비용이 동일한 프로젝트에 다른 프로젝트 / 제품에 투자하는 것보다 이점이 있습니까?

소프트웨어 마이그레이션 / 재 작성뿐만 아니라 일상적인 의사 결정에서 일반적으로 관여하는 결정을 내리기 위해 정기적 인 비용 편익 분석을 수행하고 있습니다. 따라서 가치.

환경 분리

비즈니스 이유는 환경을 분리합니다.

• 릴리스 및 버그 수정의 위험이 적습니다. 숫자로 증명하십시오. 릴리스 / 버그가 잘못되어 제품이 실패한 횟수와 고객 수익이 발생하는 횟수입니다.
• 개발 위험이 적습니다. 실수로 dev DB를 날려 버리는 것은 실수로 프로덕션 DB를 날려 버리는 것과 다릅니다.
• 역할과 액세스를 명확하게 분리하는 기능. 더 나은 보안. 생산 파이의 손가락 수를 제한하는 것이 좋습니다
• 환경을 분리 할 수있는 기능과 이러한 스타일의 개발에 따른 관행 및 절차를 통해 클라우드 시스템에 향후 구축 할 수 있습니다.
• 환경을 분리하면 동적 스케일링뿐만 아니라 스케줄에 유용 할 수있는 복제 환경의 효율성을 강제해야합니다.

모든 "올바른"주장이 이미있는 것 같습니다. 대신, 당신은 "빨간 청어"를 경험하고 있습니다. 또는 "당근 쫓기"

경영진은 중대한 문제가 생길 때까지 저를 들어주는 데 시간과 관심이 없습니다

그것이 내가 진짜 문제라고 생각하는 것입니다. 내 경험상, 회사가 당신이 묘사 한 것보다 하위 수준의 개발 관행을 가지고 있다면. 단순히 "우리는 더 잘 몰랐다"는 문제가 아닙니다. 오히려, 경영진이 야기한 문제에 대해 알지 못하는 (관리?) 기술 부채를 모은 것입니다.

그러한 경우에, 좋은 pep-talk는 당신의 방향을 갑자기 흔들지 않을 것입니다. 아마도 심각한 외상 (고객이 볼 수있는 제품 고장과 열악한 관행에 직접 연결되어 있음) 일 수도 있지만, 대화를 시도하기 전에 정통한 정통한 기술자 일 것입니다.

내 제안은 그것을 빨아 들여서 그들이 무엇인지 생각하거나 새로운 위치를 찾는 것입니다.

한 번에 몇 명의 사람들이 앱을 개발할 계획입니까? Usuaslly 나는 각 사람들 그룹에 대해 하나의 환경을 보았습니다. 이것은 개발자입니다 (DEV 환경과 DEV 통합 환경을 얻습니다-일부는 100 % 필요하지 않다고 말하고 프로젝트에 따라 다릅니다), 두 가지 테스트 환경 (한 테스터 그룹은 매우 자세한 테스트를 수행하고 다른 하나는 고급 QA 테스터-일반적으로 숙련 된 테스터가 아닌 실제 비즈니스 사용자입니다). 일반적으로 격리 된 성능 테스트 환경도 있습니다 (따라서 방대한 양의 데이터를 테스트하고 방대한 양의 사용자 등을 시뮬레이션 할 수 있습니다).

왜이 모든 환경이 필요한가? 따라서 서로 다른 그룹이 서로의 발끝을 밟지 않고도 다른 기능을 테스트 할 수 있습니다. 개발자와 테스터가 동일한 환경에서 작업하는 경우 악몽입니다. ​​테스터는 개발자가 1 분마다 적극적으로 변경하는 기능에 결함을 열 수 있습니다. 두 가지 수준의 테스트가 있으면 서로 다른 활동에 집중할 수 있으며 서로의 데이터를 엉망으로 만들지 않아도됩니다. 격리 된 성능 환경이 있으면 시스템을 정지시킬 수있는 테스트를 실행할 수 있지만 격리 된 경우 다른 테스터는 영향을받지 않습니다.

동일한 환경에서 너무 많은 사람들이 너무 많은 다른 일을하려고하면 한 그룹이 다른 그룹의 테스트가 끝날 때까지 기다리면 많은 시간을 낭비하게됩니다. Stargazer712는 시간을 낭비하고 시간을 낭비하면 돈 낭비를 초래할 수 있다고 강조했습니다.

응용 프로그램에 민감한 개인 데이터 나 신용 카드 데이터가있는 경우 일반적으로 그렇지 않은 또 다른 이유는 일반적으로 데이터를 테스트 환경에 넣을 수 없으며 일반적으로 QA 및 프로덕션 환경을 제외한 모든 것에 대한 마스킹 요구 사항이 있습니다.

직장에서 문화적 변화를 가져 오려고 많은 노력을 기울인 것 같습니다. 문화 변화는 사람들의 마음을 바꾸는 것만이 아니라 습관을 바꾸고, 편견을 어 기고, 궁극적으로 닫힌 마음을 더 큰 가능성으로 여는 것에 관한 것입니다. 따라서이 시점에서 스스로에게 물어보아야 할 질문은 "무엇을 놓쳤습니까?"입니다. 쉬운 답변은 경영진과 완전히 관계가 없을 수도 있다는 것입니다.

경영진으로부터 구매를 얻는 것은 쉽지만 더 어려워지고 있습니다. 돈 등에 관한 논쟁에 관계없이, 현실은 경영진의 우선 순위에 영향을 줄 수 있어야한다는 것입니다. 관리자에게는 예산이 있으며 예산이 현명하게 적용되고 회사의 가치와 우선 순위에 부합한다는 것을 보여주고 싶을 것입니다. 이러한 우선 순위 중 일부는 재정적이지만 다른 요구 사항은 다른 요구에 부응하는 것입니다. 어떤 경우에는 상사가 항상 원했던 승진을 얻기 위해 다른 관리자의 손바닥에 기름을 바르는 것을 의미 할 수 있습니다. 그러나 대부분의 경우 더 많은 비즈니스를 얻거나 파트너 및 고객과의 관계를 개선 할 수있는 방법을 찾는 것입니다. 이러한 조건으로 소송을 제기 할 수없는 경우, 임박한 상황에 처하기 전에는 지금까지만 갈 수 있습니다.

다른 사람들이 제안한 것처럼 생산성과 예산에 어떤 영향을 미치는지에 대한 사례를 만들려고 노력하지만 회사의 우선 순위 및 생산성이 회사와 다른 회사와의 관계에 직접적인 영향을 미치는 방식으로 사례를 제시하는 것이 좋습니다.

여기 하나가 있습니다 : 테스트 가능성.

테스트 환경이 있으면 프로덕션 환경에서 수행 할 수없는 데이터베이스에 대한 테스트를 자유롭게 수행 할 수 있습니다.

조직이 소프트웨어를 개발하는 방식을 바꾸고 싶습니까? "일을 다르게하는"것에 대한 "이유"에 대해 걱정하지 마십시오. 인간은 합리적인 주장 때문에 행동을 바꾸지 않습니다. 그들은 습관에 대한 심리적 영향 때문에 변화합니다.

그래서, 나는 이것을 어디로 가고 있습니까?

하지만 때때로 당신이 성공적으로 논증을 통해 조직의 동작을 변경할 수 있습니다, 더 잘 작동 다른 전술이있다. 여기에는 다음이 포함됩니다.

• 풀뿌리 지원 : 기회를 기꺼이 줄 다른 "레거시"개발자를 찾으십시오. 그와 파트너 관계를 맺고 일이 어떻게 진행되는지 변경하십시오. 변경 사항을 발표하지 마십시오. 그냥 변경하십시오. 누군가 당신에게 그것에 대해 물어 본다면 그냥 "오 그래, 우리가 지금하는 방법"이라고 말하십시오.

• 책임을진다. 레거시 사람들의 배치를 처리하는 자원 봉사자. 좋아하는 것처럼 행동하십시오. 그들은 그 책임을 포기하게되어 기쁘다. 그런 다음 원하는 방식으로 실행하십시오.

• 자신의 실수에 대해 올바른 사람들을 비난하십시오. 다음에 석기 시대 배포 메커니즘으로 인해 레거시 앱 버그가 프로덕션에 도입 될 때 지적하십시오. 미묘하게 ... 이메일에 없습니다. 다음에 관리자와 회의를 할 때는 배포에 문제가 발생한 이유를 간단히 언급하십시오. "응, Foo 버그 Bob이 프로덕션에 체크인했기 때문에 지난 금요일에 어떻게 혼란 스러웠는지 기억하십니까? 네, 많은 노력이 낭비되었습니다!"

• 더 나은 방법으로 쉽게 할 수 있습니다. 예를 들어, 아이폰을보십시오. 하나의 버튼이 있습니다. (둘, 둘). 매우 쉽게 켤 수 있습니다. 여러 환경에 배포하기가 매우 어리 석습니다. 모든 관리자가 쉽게 할 수 있도록하십시오!

상호 연결되거나 레거시 시스템, 비즈니스가 의존하는 시스템, 작동하고 정확한 시스템을 다룰 때 문제가 더 많습니다. 단계 사이에 분리가 필요하기 때문에 중요합니다. PROD에서 DEV를 사용하지 않는 이유 는 손실 된 시간에 수백만 달러의 피해를 입힐 수 있기 때문 입니다.

우리는 항상 동일한 하드웨어를 사용하여 DEV-> QA-> PROD (때로는 이러한 단계가 더 작은 조각으로 나뉘어 짐)를 수행합니다. 현재 생산 데이터는 항상 PROD에서 QA로 DEV로 푸시됩니다.

DEV : 개발 샌드 박스로 개발되었습니다.이 환경에서 데이터를 시도, 반복 및 구타하는 것은 결코 신뢰할 수 없으며 개발자가 문제를 해결할 수있는 방법을 찾기 만하면됩니다.

QA : 개발자가 단위 테스트에 만족하면 테스트 그룹이 눈을 떼는 시간입니다. 테스트 사례를 실행하고 성능 테스트를 수행하고 버그를 찾습니다. 이러한 버그 / 개선 사항은 DEV로 피드백되고 모든 사람이 행복해질 때까지주기가 계속됩니다.

PROD :이 단계에 도달하면 코드가 현재 데이터와 함께 작동하고 QA 그룹 / 비즈니스 사용자가 구현에 만족하는지 확인해야합니다. 모든 것을 올바르게했다면 코드를 업데이트하고 완료해야합니다.

테스트하지 않은 제품을 고객에게 출시하지 않는 것과 같은 방법으로 테스트되지 않은 코드를 프로덕션 환경에 출시해서는 안됩니다.

회사가 시간을 제대로 투자하지 않으면 비상 유지 보수 비용과 오류 10 배를 상환합니다.

작은 예로, 우리는 한 회사에서 자체적으로 생산 보고서를 변경하기로 결정했습니다. 1 년 또는 2 년 동안 다양한 문제를 해결하기 위해 우리가 들어 오기 전까지는 아무도 바뀌지 않았다.

우리가 보고서에서 불규칙성을 지적했을 때 CFO의 얼굴은 하얗게 변했고, 누군가가 빠른 변화로 인해 분기마다 ~ 250,000 달러를 잃고 있음을 알았습니다.

제대로 생각할 수 없다면 그렇게하지 마십시오.

관리는 이러한 환경을 생성하는 데 필요한 소프트웨어 회사 및 소프트웨어 제품의 성공에 큰 영향을 미칩니다. 프로젝트의 예를 들어 보자. 소프트웨어가 대규모로 개발 된 경우 프로젝트 요구 사항, 프로세스 제어, 테스트 빌드 등을 관리하지 않으면 실패 할 수 있습니다. 프로젝트 관리가 존재하도록합니다.

@ Stargazer712는 귀하의 진술이 Money 문제를 지적한다는 것에 다소 동의하지만, 소프트웨어 개발에 관한 Marc Hamilton의 저서에서 얻은 다음 진술을 확인하십시오. 신뢰할 수있는 시스템 구축 (Prentice Hall PTR, 1999, ISBN 0-13-081246- 삼). 이 모든 요소를 ​​살펴본 후; 귀하의 질문에 대한 저의 의견은 단일 환경이 당신에게 저축을주지 않는다는 것입니다. 프로젝트 / 소프트웨어를 완료하는 데 장기적인 과정을 만들 것입니다. 분산 환경을 통해 경험을 통해 통신 사업자를 시작한 스타트 업 소프트웨어 회사에서 발생한 일을 알게되고 시간과 수익을 절약 할 수 있습니다.

성공을 위해 중요한 것을 보여주는 많은 기사가 있습니다. 성공적인 소프트웨어 개발을 위해 구성 하십시오.

조직의 각 개인은 특정 기술을 보유하고 있으며 이러한 기술은 일반적으로 공식 또는 비공식 성과 지표에 대해 측정되어 향후 성과에 대한 보상으로 보상 (보상)을 초래합니다. 조직의 사람들은 일반적으로 채택되는 것으로 인식되는 행동 패턴과 가치를 가진 문화를 확립합니다.

훌륭한 소프트웨어 개발자들은 부적절한 조직 구조에 맞서 싸우는 데 모든 시간을 소비해야한다면 어려움을 겪고 결국 목표를 달성하지 못할 것입니다.

많은 소프트웨어 스타트 업은 차고에서 일하는 두 명의 개발자로 시작됩니다. 이 시점에서 회사 역사상 필요한 조직 구조는 많지 않지만 여전히 조직 구조가 존재합니다. 예를 들어 1977 년 Bill Gates와 Paul Allen이 파트너쉽을 형성하고 공식적으로 Microsoft를 지명했을 때 회사는 최소한의 조직 구조를 가졌습니다. 뉴 멕시코 앨버 커키에있는 Microsoft의 첫 번째 사무실에서 근무한 직원은 12 명도 채되지 않았으며 모든 사람이 누가 담당했는지 알았습니다. 모든 사람의보고 구조를 파악하기 위해 복잡한 조직도는 필요하지 않았습니다. 동시에 모든 직원은 회사에서 자신의 역할과 달성하려는 목표를 알았습니다. 필요한 모든 조직 구조가 각 직원간에 비공식적으로 전달 될 수 있기 때문입니다.

방법에 대한 ... 시간, 돈, 테스트 용이성, 품질을 잊어 평판 .

개발 경험이 부족한 관리자가이 아이디어를 뒷받침 할 수있는 환경을 분리해야하는 좋고 단순하며 반박 할 수없는 이유.

Uber는 최근 라이브 환경에 대한 암호가 포함 된 코드를 github에 제공 하여 '해커'가 모든 고객 세부 정보를 다운로드 할 수 있도록했습니다. Uber는 이것이 위반이라고 밝혔다. 다른 사람들은 "공개 관점에서 자물쇠에 열쇠를 넣지 마십시오. 개발자가 완전히 개발 환경에서 일했다면 github에서 개발자 환경에 대한 열쇠를 풀었을 것입니다. 프로덕션 환경에서 릴리스되었다는 것은 프로덕션 환경에서 개발을 수행한다는이 아이디어가 얼마나 나쁘다는 것을 보여줍니다.

관리자에게 실수가 발생했음을 알리기 위해 언론인 앞에서 굽고 기술 공무원이 비웃기 직전에 CEO가 그를 쫓아가는 것을 피하는 방법은 실수가 치명적이지 않도록 간단하고 분명한 조치를 취하는 것입니다 그들.

다양한 환경에 필요한 것처럼 들리며 "환경"을 설정하는 데 많은 시간이 걸립니다.

다른 "환경" 은 가장 적어야 하지만 사용자와 회사가 원하는만큼 많은 사본 을 복제 할 수 있어야합니다 ( "환경을 사용하여 시스템 구성을 의미").

최적의 차이점은 다음과 같습니다.

1. 크기 (최소, 권장, 최대 지원 / 테스트);
2. 준비 및 프로덕션에는 개발 도구가 없습니다.
3. 실수로 데이터를 덮어 쓰지 않도록 보호
4. 데모, 테스트 또는 [애노 메이션 화 된] 클라이언트 데이터를 개발 또는 스테이징 서버에 매우 쉽게로드 할 수 있습니다.

그런 다음 얼마나 많은 양의 테스트를 수행해야하는지에 대한 문제는 위험 / 비용 비즈니스 평가이며 회사 수준에서 결정됩니다. 이는 전체 고객이 중대한 결함이 다양한 고객에게 발생할 경우 고통을받을 수 있기 때문입니다. .

나중에 편집 : 이것은 내 웹 제품에 대한 명명 규칙을 합리화하도록 요청 했습니다 (질문에 감사드립니다). 나는 4 가지 "환경"을 결정했다. 테스트 기능은 qa (최소한의 단일 계층 기능 만)와 스테이징 (프로덕션과 동일한 아키텍처,로드 / 성능 / 볼륨 테스트)이다.

프로비저닝의 유일한 차이점은 프로덕션 / 스테이징 DB를 별도의 시스템에 설치하는 것입니다. DB를 다른 서버가있는 그룹으로 제어합니다. qa / dev에는 웹 서버와 db 역할이 있습니다. 로드 밸런싱은 cloudflare에 의해 수행됩니다.

또한 ENV_NO 변수가 있는데,이 변수는 시스템에 전달되므로 원하는만큼 "qa"또는 "staging"예제를 선택할 수 있습니다.

따라서 최신 백업을 포함하여 두 번째 QA 환경을 설정하려면 명령은 다음과 같습니다.

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

마지막으로, 지상에 도달하기 전에 마지막 안전망으로 "읽기 전용"이라는 추가 서버 (옵션)가 있습니다. qa 시스템과 같은 방식으로 제공되지만 지난 밤 백업 및 업데이트가 비활성화됩니다 (소프트웨어도 지난 밤으로 업데이트 됨).

"다른 바구니에있는 모든 계란"접근 방식을 사용합니다. 다른 위치 / DNS 등록 기관, DNS 호스트, 시스템 호스트 서비스 제공 업체와 함께 제공됩니다. 이것은 궁극적 / 마지막 안전망이므로 모든 것이 화염에 빠지면 적어도 어젯밤까지 데이터에 도달 할 수 있습니다. 프로비저닝 스크립트는 서로 다른 공급자 간의 차이점을 분리하므로 99 %는 동일하며 읽기 전용 플래그입니다. 모든 라이브 서버에 장애가 발생하면 Cloudflare로드 밸런서는 트래픽을 읽기 전용 사이트로 리디렉션합니다.

변경을 할 때 전문가의 의견을 듣고 제안 된 변경 사항을 구현할 사람이 있으면 운이 좋을 것입니다.

내 경험상, 나는 큰 변화를해야 할 때마다 비즈니스가 절약 할 수있는 측면에서 그것을 정당화해야했습니다. 예를 들어, 개발 파이프 라인에 ReSharper를 도입하는 작업은 매우 쉬웠습니다.

ReSharper의 개발자 비용은 약 £ 50입니다. 연간 평균 개발자 비용은 4,000 파운드입니다. ReSharper는 잠재력을 최대한 활용하여 개발자 생산성을 최소 20 % 향상시켜야합니다. 개발자가 실제로 75 %의 시간을 IDE에서 코드를 작성한다고합니다. 40k의 75 %는 £ 30k입니다. £ 30k는 이제 개발자의 생산성 비용입니다. 연간 추가 생산성 (1 %)은 300 파운드입니다. 추가 20 %의 생산성을 얻으려면 비즈니스에 £ 6k를 소비해야합니다.

이를 비즈니스에 대한 관점에서 고려한다면, 다른 사람을 고용하고 6K 파운드에 20 %의 추가 생산성을 얻을 수 있다고 말하거나, ReSharper 라이센스에 50 파운드를 소비하여 동일한 결과를 얻을 수 있습니다. 수치가 사업에 앞서면 쉽게 결정을 내릴 수 있습니다.

이제 여러 환경에 대한 질문과 관련하여 이러한 환경을 갖추기 위해 매년 비즈니스 비용을 계산하는 방법을 찾기 만하면됩니다.

동료 개발자에게 개발, 배포 등을 위해 응용 프로그램을 구성하는 데 매주 소요 한 시간을 추적하도록 요청할 수 있습니다. 예를 들어, 수석 개발자의 시간이 10 시간이면 비즈니스 £ 500가 소요될 수 있습니다. 개발에 훨씬 더 중요한 10 시간이 소요됩니다. 일정 기간 동안 수치를 수집하여 연간 비용을 비즈니스에 제공합니다.

나는 이런 종류의 정치를 개인적으로 미워하지만 그것은 일반적이며 우리는 그와 함께 살아야합니다.