나는 더 큰 조직을 지원하는 작은 프로그래밍 팀에서 일합니다. 올해 관리자는 Oracle Apex 기술을 사용하여 대다수의 회사 데이터를 처리하기로 결정했습니다.

Apex 서버가 하나만 있다는 점을 제외하면 괜찮습니다. 우리 관리자는 모든 상황이 해당 인스턴스에서 발생한다고 결정했습니다. 우리 팀은 앱을 개발하고 있으며, 관리자 데모와 내부 고객이 앱을 사용하고 있습니다.

Apex에 더 많이 투자하고 앱이 더 복잡해지고 사용자 수가 증가함에 따라이 상황이 더 악화 될 것으로 예상 할 수 있습니다. 모범 사례는 별도의 개발, 테스트 및 프로덕션 환경을 갖추는 것이지만 왜 그런가?

질문 : 왜 별도의 개발, 테스트 및 프로덕션 환경이 있어야합니까?

왜 별도의 개발, 테스트 및 프로덕션 환경이 있어야합니까?

여러 활동이 동시에 진행 중입니다.

• 개발-개발자가 코드를 저지르고 실수를하거나 실험하는 등
• 테스트-테스트가 수동 또는 자동으로 실행되며 복잡성으로 인해 많은 리소스가 소비 될 수 있습니다.
• 생산-고객 및 / 또는 비즈니스를위한 가치 창출

이 모든 것들이 같은 환경에서 일어나기를 원하십니까? 새로운 테스트로 인해 서버가 하드 드라이브를 교체하고 프로세서의 모든 코어를 소비하기 때문에 비즈니스가 중단 되길 원하십니까? 개발자가 스케일링 실험에서 복잡한 포크 폭탄을 만들었 기 때문에 테스트가 중단되기를 원하십니까? 테스트에서 개발자의 꼬기와 덕트 테이프로 인해 작동한다고 생각되는 코드를 프로덕션에서 실행 하시겠습니까? 잠재적으로 민감한 프로덕션 데이터로 작업하는 개발자를 원하십니까 (모든 비즈니스에서 문제가되지는 않지만 많은 데이터가 있다는 것을 알고 있습니다)?

이러한 문제가 발생하지 않는 이유는 무엇입니까?

별도의 환경.

그래서 무엇이 필요합니까?

별도의 환경이 필요합니다.

공식적으로 넣어

다음과 같은 이유로 별도의 환경이 필요합니다.

• 비즈니스 및 소프트웨어 개발 차단 위험을 줄입니다.
• 개발자의 임시 리깅으로 인해 테스트를 통과 한 프로덕션 환경에 코드를 넣을 위험을 줄입니다.
• 생산 데이터가 잘못된 손에 들어갈 위험 (조직이 ID 번호 및 재무 및 건강 정보와 같은 민감한 데이터를 처리 할 때 매우 중요) 또는 테스트 데이터와 혼동되거나 파괴 될 위험을 줄입니다.

귀하의 상황에 맞는 새로운 기술 플랫폼

어쩌면 이것이 실제로 생산되지는 않지만 (상대적으로 새로운 플랫폼이기 때문에) 비즈니스가 의존하기 시작할 때 별도의 환경을 얻을 수 있으며 위험을 예측하거나 어려운 것을 배우면 실현할 수있는 현명합니다. 방법.

모범 사례는 별도의 개발, 테스트 및 프로덕션 환경을 갖추는 것이지만 왜 그런가?

요즘 분명하게 자르지 않았습니다.

많은 곳에서 더 이상 수동 테스트를 수행하지 않으므로 테스트 데이터가 없습니다. 더 많은 장소에는 그러한 규모가있어서 비용 때문에 생산 환경을 재현 할 수 없습니다. 특히, 마이크로 서비스가 폭발적으로 증가함에 따라 QA 환경에서의 테스트가 생산 과정에서 나타날 수있는 버그를 정확하게 포착 할 수 있도록 빠르게 변화하는 환경을 동기 상태로 유지하는 것은 어려운 일이되었습니다.

왜 별도의 개발, 테스트 및 프로덕션 환경이 있어야합니까?

• 사용자가 테스트 데이터를 볼 수 있다면 매우 나쁠 것입니다.
• 개발자 / 테스터들이 당신의 제품 데이터를 보는 것이 매우 나쁠 것입니다.
• 개발자가 나쁜 것을 깨뜨리지 않는다고 믿을 수 없다면 그 상황을 빨리 해결할 수 없습니다.
• 코드를 빠르고 쉽게 홍보 할 수 있도록 CI를 자동화 한 경우.

본질적으로, 환경을 가진 비용이 비용보다 작 으면 없는 환경을 가지고 .

주된 (가장 명백한) 이유는 테스트 및 생산 데이터를 혼합하지 않기 때문입니다. 이것은 시스템 사용자와 개발자 모두에게 매우 혼란 스러울 수 있습니다. 품질 보증 및 단위 테스트 (수행해야 할)를 관리 할 때는 완전히 분리 된 환경에 있는지 확인해야합니다. 개발 환경이나 QA에서 폭발이 발생하면 프로덕션 환경에 부정적인 영향을 미치므로 실제 사용자와 중요한 데이터에 영향을 미칩니다! 당신은 이것이 생산에 영향을 미치 길 원하지 않습니다!

이것은 버전 관리와 같은 일상적인 작업에서 사용해야하는 일반적인 서비스로 확장됩니다. 제어하는 코드가 실제 환경에있는 경우 버전 제어를 제대로 사용할 수 없습니다! 사용자가 제정신이 될 것입니다. 되돌 리거나 롤백해야하는 경우 어떻게해야합니까? 15 번의 커밋이 심오한 실수를한다면? 분기를 어떻게 처리합니까?

최소한 환경을 여러 가상 인스턴스로 분리해야하지만 실제로 말한대로 정확하게 수행하고 각 환경에 대해 완전히 별도의 인스턴스를 가져야합니다. 이상적으로 개발, QA, 준비 및 생산.

이 모든 것은 궁극적으로 전면 응용 프로그램 (및 사용자에 대한 평판)뿐만 아니라 팀의 효율성에도 엄청난 해를 끼칩니다.

사용 가능한 Oracle 인스턴스가 하나만 있다고 "개발, 테스트 및 프로덕션 환경이 분리되지 않음"과 같은 의미는 아닙니다!

당신은 의견을 썼습니다

우리는 현재 프로젝트마다 다른 스키마를 사용합니다.

따라서 일부 프로젝트는 개발 전용으로, 일부는 테스트 용 으로 만 사용하면 다른 스키마를 사용하여 환경을 어느 정도 분리 할 수 있습니다 . 인스턴스 분리가 계획되지 않은 경우 알 수있는 유일한 합리적인 접근 방식이므로 이미이 작업을 수행했다고 생각합니다. 관리자가 너무 정신이 없어 개발자 데이터, 테스트 데이터 및 고객 데이터를 하나의 스키마로 임의의 방식으로 혼합하기를 원한다고 상상할 수 없습니다. 그는 아마도 두 번째 서버를 구입하지 않고 두 번째 인스턴스의 라이센스에 돈을 투자하여 돈을 절약하려고 할 것입니다.

따라서 실제로 물어봐야 할 질문은 다음과 같습니다.

개발, 테스트 및 프로덕션 환경을 분리하기 위해 다른 인스턴스 및 / 또는 서버를 사용해야합니까, 아니면 스키마 분리로 충분합니까?

따라서 다른 답변과 같이 답변이 명확하지 않습니다. 다른 스키마는 다른 액세스 권한을 허용하므로 하나의 Oracle 인스턴스 내에서 어느 정도 격리 할 수 ​​있습니다. 그러나 개발자는 "그들의"스키마 내부에 약간의 관리 권한이 필요할 것이므로 인스턴스를 하나만 사용하는 경우 프로덕션 데이터에 액세스 할 수 없도록하는 것이 더 어려울 것입니다.

또한 하나의 인스턴스 / 서버는 공유 사용자 / 스키마 관리, 공유 디스크 공간, 공유 CPU, 공유 네트워크 대역폭 등 개발, 테스트 및 프로덕션 간의 공유 리소스를 의미합니다. 이것을 "누수 추상화 법칙" 과 결합 하나의 인스턴스 만 사용하면 개발 환경, 테스트 환경 및 제품 환경간에 원치 않는 부작용이 발생할 위험이 있음을 알 수 있습니다.

결국, 당신은 스스로 결정해야합니다 : 당신은 접근 방식의 단점을 효과적으로 사용할 수 있습니까? 애플리케이션이 리소스를 많이 사용하지 않고 프로덕션 데이터가 "비밀"이 아니기 때문에 "3 개의 인스턴스 / 3 개의 서버"에서 얻을 수있는 수준보다 개발, 테스트 및 프로덕션 간의 분리 수준이 감소하는 것이 허용됩니다. 접근하다? 이러한 방식으로 효과적으로 작업 할 수 없거나 고객을 잃기 시작하는 방식으로 생산을 방해 할 위험이 없으면 관리자가 최소한 두 번째 서버를 구매하도록 설득해야하는 모든 주장이 있습니다.

각 환경에는 여러 환경 유형이 필요하며 여러 서버가 필요할 수도 있습니다.

개발자는 개발중인 코드를 업데이트 할 수 있습니다. 코드가 작동하지 않을 수도 있습니다. 응용 프로그램이 시작되지 않을 수도 있습니다.

자체 환경에서 최신 안정적인 빌드를 테스트하는 QA에는 영향을 미치지 않습니다.

개발 및 QA가 환경을 업데이트함에 따라 프로덕션은 6 개월 전의 최신 릴리스 빌드에 있으며 다른 환경의 변경에 영향을받지 않습니다.

다양한 환경에서 롤아웃되는 이러한 변경 사항은 코드 또는 데이터 일 수 있습니다. QA는 프로덕션에서 일부 불량 데이터를 수정하도록 설계된 데이터베이스 스크립트를 테스트해야합니다. 스크립트로 인해 문제가 악화 될 수 있습니다. 데이터베이스 백업을 복원하고 다시 시도하십시오. 그것이 생산에서 일어난다면, 당신은 매우 심각한 재정적 문제를 겪을 수 있습니다.

릴리스가 여러 개인 경우 어떻게됩니까? 아마도 2.0 버전을 개발하고 있지만 1.0 유지 보수 브랜치에서 여전히 버그 수정 릴리스가 필요합니다. 이제 중요한 버그가 발견되어 어제 수정해야 할 때 항상 두 가지를 개발하고 테스트 할 수 있도록하려면 여러 개발 및 QA 환경이 필요합니다.

별도의 환경이 없는 문제는 이미 눈치 notice습니다 . 바로 여기에는 개별 환경에 대한 근본적인 이유가 있습니다. 단일 환경에서 개발, 테스트 및 생산 작업을 수행 할 때 필연적으로 발생하는 충돌로 인한 문제를 제거하는 것입니다. 개발자들에게 개별 샌드 박스를 제공하는 데 동일한 추론이 적용되며, 한 명의 개발자의 실수 또는 심지어 전체 개발 팀을 무너 뜨리는 것만으로도 호환되지 않는 변경 사항이 유지됩니다.

이는 단일 환경에서 벗어나 변화를 관리하기 위해 관리 할 수있는 가장 좋은 주장이기도합니다. 단일 환경에서 이미 발생하고있는 문제를 지적하고 추세선을 표시하며 상황이 계속 진행될 경우 조만간 논의 별도의 환경을 위해 재구성하는 것보다 정리하는 데 훨씬 많은 비용이 드는 문제 (직접적인 노력과 회사의 서비스 제공 능력에 대한 고객의 신뢰 상실).

많은 반대 세력과 역학이 있습니다. 많은 서버가 있고 하나만 있으면됩니다. 이 질문이 단순한 데이터베이스 이상의 영향을 미칠 수 있다고 생각합니까? 나는 오해를 불러 일으킬 수 있지만, 그것은 유형 대 추상의 비용이 있다는 체계적인 오해와 관련이 있습니다.

일반적으로 명백한 비용은 이해하기 쉽습니다.

추상 비용은 정량화하기 어렵고 이해하기가 어렵습니다. 기술 부채, 오류 비용, 스트레스 비용, 개발자 부담, 변경 영향, 회귀 테스트, 다운 타임 영향 등은 설명하기가 더 어렵습니다.

다른 환경 환경은 일반적으로 데이터 및 / 또는 목적으로 분리됩니다. 환경마다 기능이 다릅니다. 시스템의 변화율, 즉 얼마나 자주 업데이트되는지, 어떤 종류의 변화 및 변화의 영향이 모두 고려됩니다.

우리는 변화를 사소한 다른 환경을 사용합니다.

우리는 서로 다른 환경을 사용하므로 변경되지 않은 환경에 대한 견고성과 확실성을 제공합니다.

우리는 변화의 영향을 고려하기 위해 환경을 사용합니다.

우리는 변화와 관련된 비용을 줄이기 위해 환경을 사용합니다.

시스템을 테스트하고 안정화하는 데 많은 비용이 듭니다 . 안정적인 환경에 대한 투자를 확보하기 위해 환경을 만듭니다.

실용적이고 비용을 절감하며 부지런하고 입증 된 프로세스 패턴을 준수하기에는 너무 작은 팀이 아닙니다.

모든 환경에 하나의 환경을 사용하는 것은 모든 사진을 하나의 하드 드라이브에 저장하는 것과 같습니다. 할 수는 있지만 후회하게됩니다.

어떤 사람들은 견고 함을 보장하고 모범 사례를 따르는 데 드는 비용을 인식하지 못하는 고객이나 다른 사람들을 다루는 많은 상황에서 내가 증거를 필요로 합니다. 비용이 명확하게 정의 된 실제 사례의 몇 가지 예를 정리해 보시기 바랍니다.