프로덕션 서버에서 개발

오늘 저는 프로덕션 서버에서 응용 프로그램을 개발 한 것에 대해 소리 쳤습니다. " 제작 서버에서 개발하는 것은 허용되지 않습니다. "

여기 상황이 있습니다.

1. 개발 인스턴스를 설정했습니다. http://example.com:3000
2. 프로덕션 인스턴스는 다음과 같습니다. http://example.com
3. 나는 모든 개발 작업을 완료 http://example.com:3000하고 고객이 변경 사항에 만족하면로 변경합니다 http://example.com.

내가 작업하고있는 응용 프로그램은 오래된 Ruby on Rails 응용 프로그램이며 처음에는 개발 환경을 로컬로 설정하려고 시도했지만 절대 실행할 수는 없습니다. 잠시 동안 노력한 후 포기하고 프로덕션 서버에서 개발하기로 결정했습니다.

다시, 나는 바보인가? 아마 그렇습니다.하지만 지금은 몇 년 동안 웹 개발을 해왔으며 이런 상황에 처한 적이 없습니다. 누가 옳고 왜?

프로덕션 서버에서 개발 했었습니다. 그것은 잘 작동 할 수 있지만 적어도 두 가지 이유로 인해 바람직하지 않습니다.

1. 개발 코드는 무한 루프, 메모리 누수 또는 기타 문제를 일으켜 CPU를 잠 그거나 모든 메모리를 사용하지 않거나 프로덕션 코드에 영향을주는 방식으로 서버에 영향을 줄 수 있습니다.
2. Ruby 또는 MySQL 버전과 같은 개발 작업의 일부로 서버 환경의 구성 요소를 변경해야하는 경우 바인드 상태가됩니다.

다른 사람들이 말했듯이 PROD 환경에서 코딩하면 사용자가 버그에 노출됩니다. 다른 인스턴스를 시작한 경우에도 여전히 공유 하드웨어 리소스가 있으며 프로덕션 파일 및 데이터베이스에 계속 액세스 할 수 있습니다. 의견 중 일부는 지적로 데브 인스턴스가 해킹 된 경우에, (예를 들어, 당신은 그것을 닦아하는 것을 잊지 누군가는 대규모 보안이 레일에 악용 발견하기 때문에), 지금과 공개적으로 액세스 할 수있는 기계를 가지고 당신의 응용 프로그램 연기 게이트웨이로. 안타깝게도 ...

기업마다 이에 대한 응답이 다르지만 일반적으로 다음과 같이 분류 할 수 있습니다.

• 스크류 업이 발생 했습니까?
• 변경 사항을 되 돌리는 데 시간이 얼마나 걸립니까 (주로 C ++에서 작업하므로 바이너리를 롤백하는 것은 Ruby보다, 특히 오래된 바이너리를 "잃어 버렸고"다시 컴파일해야 할 때) 훨씬 오래 걸릴 수 있습니다
• 어떤 변화의 효과 (거친 가이드 : 저장된 데이터를 망쳐 것은 그래서 훨씬 더 저장하거나 차례로 모두에서 페이지를 표시하지 않는 것보다 더 나쁘다 데이터를 표시하지 않는 것보다)
• 당신이 망쳐 서 문을 나갔다면, 당신이 한 일을 아는 사람이 있습니까?
• 충돌 전에 나사산을 방지 / 최소화 / 감지 할 수있는 다른 배포 옵션이 있습니까?

이것은 당신에게 최종 계산을 제공합니다 :

• 완벽하게 예방할 수있는이 사업은 비용이 얼마나 듭니까?

이제 예산 결정을 내리는 사람 에게 전체 관리 구조의 가치가 훨씬 떨어 집니다. 따라서 소리 쳤다.

회사의 내부 "회사 정보"페이지에서 작업 중이고 자신의 이름을 L. "하나님과 같은"토마스로 바꾸는 경우 닉네임 문제를 당황하게합니다. 비즈니스 크리티컬 구매 앱을 개발하는 중에 실수로 신용 카드 세부 정보를 홈페이지에 디버깅하는 소송이 발생합니다. 이러한 극단 사이에는 잘못된 충전, 생산성 저하 및 고객을 몰아 낼 수있는 다른 모든 것들이 있습니다.

"회사 소개"페이지에서도 허용되지 않는 이유 는 프로덕션 환경에서 직접 코딩하는 것이 중독성 이 있기 때문 입니다. 미성년자를 위해서만 시작하지만 시간이 지남에 따라 DEV 환경을 처음부터 다시 시작할 필요가 없습니다.

그 외에도 비즈니스 규모가 큰 영향을 미칠 수 있습니다. 두 사람의 팀에서 무언가가 푸트되면 어깨 너머로 "Oi, jackass, put it back"으로 가십시오. 300 명 규모의 회사에서는 무능하거나 악의적 인 것인지 걱정해야하고 관리자는 통제 할 수없는 물건에 대해 책임을 져야합니다.

하루가 끝나면 절차를 따르고 실수하면 절차에 어떤 문제가 있는지 확인합니다. 절차를 망쳐 놓고 조롱하면 책임이 조금씩 퍼져도 이제는 혼자 책임이 있습니다. 당신이 주사위를 굴릴 것인지는 당신에게 달려 있습니다.

개발 환경을 로컬로 설정하려고했지만 실행할 수 없었습니다. 잠시 동안 노력한 후 포기하고 프로덕션 서버에서 개발하기로 결정했습니다.

프로덕션 서버 에서 AVOID 개발에 대한 진술 을 지원 합니다. 구성 파일의 오타 수정이고 관리자가 요청한 경우 GUN 하에서 만 수행 할 수 있습니다.

WHY NOT?-매우 위험하고 나중에 습관 을 들이는 경향이 있기 때문에 심하게 잡을 수 있습니다. 치명적인 생산 오류 / 실패로 인해 직장에서 해고 당할 수 있습니다.

나를 다시 반복 처리를 다시 보자 당신이에 오타 수정을 요청하는 경우도-하지만 production, 서버 처음 에 그것을 할 Staging. 즉, 변경 사항을 테스트하고 테스트 한 다음 프로덕션에 배치하기 전에 다시 테스트하십시오.

이것은 " 빠르고 더러워지다 " 라는 문화가 표준으로 보이는 곳에서 자주 발생하는 일 입니다.

편집 : 별도의 환경으로 프로덕션 서버에서 개발하는 것도 허용되지 않습니다 . 업무상 문제가 발생하면 프로덕션 서버가 다운 되어 프로덕션 애플리케이션 성능에 영향을 줄 수 있습니다. 예를 들어, 이전 동료가 개발 목적으로 프로덕션 서버 WinServer 2003을 사용하려고 할 때 보안 허점이있는 경우를 기억합니다.

이것은 실제로 프로토콜 문제입니다. 일반적으로 이것은 당신이하고 싶은 것이 아닙니다. 생산 기계를 그대로 두려고합니다. 중요한 데이터가 포함되어있을 수 있으며 프로덕션 준비가되지 않은 코드로 프로덕션 사이트의 성능이나 안정성을 손상시키지 않으려는 경우.

즉, 이것이 일반적으로 수행되는 시간이 있습니다. 트래픽이 적은 brouchureware 또는 간단한 CMS 사이트를 펌핑하는 위치에 있다면 이는 문제가되지 않을 것입니다. 그러나 민감한 데이터 또는 "비즈니스 크리티컬"프로세스로 작업하는 경우 동일한 머신에서 개발 코드를 사용할 위험이 없어야합니다.

프로덕션에서 직접 개발하지 않는 또 다른 중요한 이유는 개발 인스턴스가 일반적으로 자세한 오류와 스택 추적을 생성하고 표시하기 때문입니다. 당신은 결코 사용자에게 그것을 보여주고 싶지 않습니다.

그렇습니다. 클라이언트에 표시하는 대신 로그를 기록 할 수 있지만 디버깅 은 기존보다 훨씬 덜 재미 있습니다.

추가 개발 인스턴스에 문제가 당신의 측면 문제를 주소 : 나는 배포 큰 성공 했어 버추얼 와 우리의 생산 환경 (물론, 하드웨어 제외) 복제 VM 기반의 우분투 서버를 .

아직 가장 중요한 이유를 언급 한 사람이 아무도 없습니다. 프로덕션 서버에서 개발하는 것이 절대적으로 금지 된 이유는 무엇입니까?

너무 쉽게 일어날 수있는 생산 데이터를 망쳐 놓지 마십시오!

한 곳에서 작은 오류가 발생하면 다른 계산에서 막대한 문제가 발생하고 다음 날에는 모든 데이터가 쓰레기이며 고객이 화나게됩니다. 이것은 UI의 버그 또는 여기 저기 충돌보다 훨씬 나쁩니다.

대부분의 응용 프로그램에서 값은 루틴이 아닌 데이터에 있습니다.

나는 항상 다른 개발자에게 특정 회사의 절차가 무엇인지 묻고 노력합니다. 일반적으로 그렇습니다.

1. 로컬로 구축하십시오.
2. 가능한 한 생산을 모방하는 상자 유형으로 밀어 넣어 그것이 잘 재생되는지 확인하십시오.
3. 변경 사항을 검토하기 위해 QA 또는 인증 인스턴스로 푸시하여 클라이언트 / QA 팀에 전달할 수 있습니다.
4. 생산을 추진하십시오.

GitHub 와 페어링 된 Capistrano 레시피 를 사용 하여이 모든 것을 처리 할 수 ​​있습니다. 매번 손으로이 작업을해야한다면 빨리 늙을 수 있습니다.

prod를 개발할 때의 또 다른 문제점은 때때로 소스 컨트롤에서 이러한 것들이 누락되어 향후 릴리스에서 빠른 수정 변경을 취소 할 수 있다는 것입니다.

미국에서 상장 된 회사에있는 경우 규제적인 이유로 제품에 액세스 할 수 없습니다. 일반적으로 어떤 회사에서도 개발자가 (모든 답변에 명시된 공명과 가능한 법적 이유에 따라) 자극을받지 않아야하므로 관리자는 귀하에게 해당 서버에 대한 권한을 허용하는 데 잘못되어 있습니다.

"항상"또는 "절대로"를 사용하는 규칙은 일반적으로 잘못 정의되어 있습니다. 모범 사례를 어기는 것이 정당한 경우가 있습니다. 훨씬 좋은 조언은 "아주 좋은 이유가 없다면 프로덕션 서버를 건드리지 마십시오"입니다.

내 경력에서 프로덕션 서버의 코드를 변경 해야하는 이유는 두 가지뿐입니다.

1. 개발 환경에서만 발생하고 재현 할 수없는 버그 또는 동작 이것들은 드물지만 매우 성 가시고 찾기가 어려울 수 있습니다.

2. 몇 분 이상 걸리는 경우 일반 배포 프로세스를 통과 할 때까지 기다릴 수없는 중요한 버그를 직접 수정하십시오. 이 후 관리와 함께 지워졌습니다. 운이 좋으면 전체 경력을 위해 그 중 몇 개만 있어야합니다.

둘 다 시스템을 잘 알고있는 선임 개발자에게 가장 좋습니다.