버전 관리 및 지속적인 통합을 사용하지 않는 심각한 회사가 있습니까? 왜?

필자의 동료는 지속적인 통합이 가능한 빌드 서버와 버전 제어 소프트웨어를 모두 사용하여 소프트웨어 부서가 고도로 발전했다는 인상을 받았습니다. 나는 진지한 소프트웨어를 만들었고 어느 ​​것도 가지고 있지 않은 회사를 알고 있기 때문에 이것은 내 견해와 일치하지 않았다. 그러나 제 경험은 소수의 회사에만 국한됩니다.

소프트웨어 비즈니스에 있으며 이러한 도구를 사용하지 않는 실제 회사 (3 프로그래머 이상)를 아는 사람 이 있습니까? 그러한 회사가 존재한다면 그렇게하지 않을만한 충분한 이유가 있습니까?

나는 당신이 그들을 심각한 행동이라고 부를지 확신하지 못하지만 MySpace는이 전선에서 꽤 가난합니다 : http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .

현실이 상식적으로 무엇을 할 수 있는지 보는 것에 놀랄 것입니다. ;-)

버전 관리 시스템을 사용하지 않는 회사가 여전히 많다고 생각합니다. 내가 지금까지 본 모든 경우에 흥미롭게도 그러한 시스템의 사용을 기꺼이 반대하기 때문이 아니라 SVN과 같은 것이 존재한다는 것을 모르기 때문입니다! 나에 관해서는 : 나는 당신에게 전적으로 동의하며 어떤 종류의 버전 제어를 사용하고 싶지 않은 상황을 이미지 할 수 없습니다. 나도 집의 PC에있는 개인 파일 (워드 문서 등)을 GIT 저장소로 푸시하고있다.

지속적인 통합 시스템의 경우 일상적인 작업에 사용하지 않는 것이 일반적입니다. 때때로 사람들은 그러한 시스템이 존재한다는 것을 알지 못하지만 사용하지 않는 것에 대한 매우 의심스러운 변명은 "우리는 충분히 복잡하지 않다"거나 "지속적인 통합 없이는 매우 잘 작동하고 있습니다. 왜 다른 기술을 추가해야합니까? " 물론 그것은 현실적인 평가를 의미하지는 않지만 원래의 질문에 대답 하는 것은 드문 일 이 아닙니다.

현재 업계 (뱅킹)의 거의 모든 회사에서 버전 관리를 사용합니다. 그러나 버전 제어없이 소프트웨어를 성공적으로 개발할 수 있습니다. 20-30 년 전에 우리는 정확히 그렇게했습니다.

많은 은행들, 심지어 대다수 은행들이 지속적인 통합으로 빌드 서버를 사용 하지 않는다고 말합니다 . 지속적인 통합없이 소프트웨어를 이미 성공적으로 제공하고 있다면 그 길을 계속 이어가는 것이 합리적입니다.

@RoadWarrior의 답변에 반박을 제시하기 만하면됩니다.

저는 은행에서 일합니다. 지난 3 년 동안 버전 제어를 구현했으며 이제 코드베이스의 약 20 %에이를 관리했습니다. (대규모로 약 20 명의 개발자가 있으며 16 년 이상 시스템을 개발했습니다)

업계 내 연락처 (뱅킹)를 통해 톤 제정신 사람이 버전 제어라고 부르는이없는 다른 금융 기관의.

그렇습니다. 우리 업계 (소프트웨어 개발)는 대부분의 사람들이 인정하고 싶은 것보다 훨씬 슬프습니다.

버전 관리 : 25 년 전 첫 직장에는 이와 같은 버전 관리 시스템이 없었지만 PDP-11의 RSX11이었습니다. 그러나 디자인과 코드에 대한 공식적인 검토를 통해 매우 높은 수준의 품질 관리가 이루어졌습니다 (이것은 원자력 산업에있었습니다).

그 이후로 모든 작업은 SCCS, PVCS, clearcase, cvs 및 perforce를 포함한 버전 제어 시스템을 사용했습니다.

내 경험에 따르면 버전 제어의 사용은 심각한 소프트웨어 개발에서 거의 보편적입니다.

지속적인 통합 : 특히 자동화 된 테스트 방법이 많지 않은 레거시 코드가 많은 곳에서 문제가됩니다. 기존 코드를 CI 환경으로 옮기는 데는 큰 투자가 필요하지만 결국에는 성과를 거두지 못할 수도 있지만 경영진이 단기적으로 이익을 얻기 위해 그러한 투자에 투자하는 것은 어렵습니다.

나는 어떤 프로젝트를 위해 CI를 가지고있는 한 곳 (큰 은행)에서 일했고, 우리는 프로젝트를 좀 더 쉽게 해주었지만 약 6 개월이 걸리는 일종의 CI 시스템을 구현했습니다.

나는 대부분의 회사들이 이러한 것들을 사용하지 않는다고 생각할 것이다. 왜냐하면 그들은 이익을 이해하지 못하기 때문에 개발자들은 배우고 싶지 않거나 자신의 방식과 다른 일을함으로써 "냄비를 약동하기"를 두려워하기 때문이다. 전에 했어.

지금은 직원이지만 데이터베이스 컨설턴트로 자영업 했었습니다. 수년 동안, 나는 엄마와 팝 레벨에서 포춘 100에 이르기까지 800에서 1000 회사 사이에있었습니다.

지속적인 통합이 이루어지는 곳은 상대적으로 적었지만 버전 관리를 사용하지 않는 회사를 본 적이 없습니다. 버전 제어 코드를위한 중앙 집중식 저장소가없는 곳을 보았습니다. 개별 프로그래머는 자체 컴퓨터에서 버전 제어를 사용하거나 서버의 홈 디렉토리 아래에 버전 제어 코드를 유지했습니다.

나는이 회사들 중 어느 것도 소프트웨어 사업에 있다고 생각 하지는 않지만 그들의 프로그래머는 확실히 있었다.

저의 동료는 지속적인 통합이 가능한 빌드 서버와 버전 제어 소프트웨어를 모두 사용하여 소프트웨어 부서가 고도로 발전했다는 인상을 받았습니다.

아니, 나는 그것을 말하기 싫어하지만 이것은 사실이다. 내가 일한 마지막 두 곳 (은행과 금융 회사)은 버전 관리 시스템을 구현 한 곳이었습니다. 많은 장소 (특히 소프트웨어가 아닌 상점)는 왜 장기 개발에 실제로 필요한지 이해하지 못합니다. 팀은 일반적으로 한두 사람으로 시작한 후 고통 스럽지만 거기서 자랍니다. 한 사람 또는 두 사람이 있으면 거의 끊임없는 의사 소통을 할 수 있기 때문에 잘 지낼 수 있습니다.

지속적인 빌드는 완전히 다른 경우입니다. 내가 추측해야한다면 개발이 완료된 곳의 거의 90 %가 CI 솔루션을 가지고 있지 않다고 내기 할 것입니다. 나는 회의에 갔는데 대부분의 사람들은 MS 나 구글 이외의 조직이 그것을 가지고 있다는 것에 놀랐다. 내가 찾은 것은 많은 시간을 절약 할 수 있지만 경영진이 소액의 돈을 쓰고 운영하기를 원하지 않는다는 것입니다.

내가 찾은 가장 큰 이유는 다음과 같습니다.

1. 경영진은 같은 조직의 순위를 통해 상승했습니다. 그들은 결코 사용하지 않았고 필요하지 않았습니다. 왜 지금 바꿔야합니까? 내가 찾은 일부는 변화를 두려워합니다. 새로운 것이 무섭기 때문에 오래된 컴파일러에서 먼지를 제거하지 못하고 필요할 때 어린 아이들을 도울 수 있습니다. 다른 때는 (그리고 더 자주) 예산이 항상 빡빡하며 돈을 어디에 쓸 것인지 결정해야합니다. 이를 구현하는 것은 분명한 요구이지만, 우리가 이전에 사용했기 때문입니다. 우리는 이점을 알고 있지만 그렇지 않습니다.

2. 관리자는 IT가 아닌 사람이며 여기에서 필요한 것은 이전에는 필요하지 않은 것에 돈을 쓰고 싶다는 것입니다.

내가 사람들로부터 들었던 대부분의 주장은 모범 사례 등을 중심으로하며 사실이지만 대부분의 개발자는 이해하지 못하는 것은이 시나리오에서 재정 상황의 관점에서 프레임을 구성해야한다는 것입니다. 이 금액을 사용하면 X 시간을 절약 할 수 있으며이를 백업하려면 숫자가 필요합니다. 이것은 항상 사실은 아니지만 과거에 저의 경험이었습니다.

많은 사람들이 스스로 코딩하고 소스 코드를 중앙 서버 나 USB 하드 드라이브에 주기적으로 백업하는 데 사용되기 때문에 소스 제어를 사용하지 않는다고 말합니다. 나는 약 1 년 전에 SVN을 사용하도록 시작했습니다. 장기적으로 유익하다는 것을 알았 기 때문입니다. 익숙해지기까지 시간이 걸렸지 만 이제는 끊임없이 참조 할 수있는 수많은 코드 기록이 있습니다. 4 년 전에 시작했을 때 구현했으면 좋겠습니다.

지속적인 통합? 필요한 경우에만 사용하십시오. 저에게는 소프트웨어 엔지니어가 두 명뿐이므로 자체 소프트웨어를 직접 작업하기 때문에 지속적인 통합의 이점을 얻지 못할 것입니다.

하, 당신은 당신이 SCM과 CI 시스템을 가지고 있기 때문에 당신이 진보했다고 생각합니까? 그것이 끝나는 아마추어 시간이라고 말해 드리겠습니다.

많은 회사들이 필요한 최소한의 작업을 수행 합니다 . 그것이 실제로 필요한 전부이기 때문입니다 . 그것이 효과가 있고 큰 노력없이 재현 가능한 좋은 릴리스를 얻는다면 고칠 필요가 없습니다. 이러한 상황에서 마지막으로 수행하려는 작업은 특히 관리자 리소스를 업무에서 분리하여 새 서버를 설정하고 관리하고 시스템을 구축 할 때 문제를 해결하는 것입니다.

그러나 일부 회사는 일단 빌드를 수행 할뿐만 아니라 테스트 계획 및 테스트 결과를 통해 배포에 이르는 모든 요구 사항을 코드 검토, 워크 플로 스타일 체크인 절차 및 팀 리더 지정 작업 패키지 관리. 그것은 실제 구성 관리이며, 그런 종류의 환경에서 일할 필요가 없다는 것을 기쁘게 생각합니다!

나는 몇몇 회사에서 일한 적이 있는데 어떤 형태의 SCM이없는 것은 생각할 수 없습니다. 그들 중 일부는 다른 것보다 포괄적이었습니다. 그러나 그들 모두는 VSS를 사용하는 시스템까지도 잘 작동하는 시스템을 가지고있었습니다.

복잡한 응용 프로그램에서 작업 할 때 두 명의 프로그래머와 작업 목록을 사용하더라도 서로의 변경 사항을 망치지 않는 것이 어려울 수 있습니다.

이전 릴리스 관리 소프트웨어조차도 변경 사항을 나란히 표시하고 어느 방향 으로든 적용 할 수있었습니다. 변경 사항이 없으면 변경 사항이 두 번 이상 누락되었을 수 있습니다.

CI로 인한 많은 이점을 볼 수 있지만 어떤 회사가 버전 제어 소프트웨어를 사용하지 않는 이유는 상상할 수 없습니다.

제가 버전 관리없이 일한 마지막 일은 2006 년이었습니다 (저는 웹 개발자, FWIW입니다). 회사는 저를 고용하기 전에 약 2 ~ 3 명의 개발자 만 있었지만, 불과 몇 달 만에 10 명 정도의 개발자가 채용되었습니다. 내가 고용했을 때 내가 한 첫 번째 일 중 하나는 버전 제어 (CVS, 내가 얼마나 심하게 빨랐는지 알지 못했기 때문에!)를 소개하는 것이었지만, 나 이후에 고용 된 많은 개발자들은 자신의 개발 작업을 할 수 없었습니다. 환경을 사용하지 않았습니다. 아, 응용 프로그램의 로컬 인스턴스가 실행 중이 아니라고 언급 했습니까? 그들은 서버에서 코드를 해킹했습니다. 물론 자동화 된 테스트도 없습니다. 다시 생각하면 울었습니다.

그 전에는 버전 제어없이 일부 AS / 400 프로그래밍 작업을 수행했습니다. 해당 환경에서 적절한 VCS를 사용할 수 있는지 여부를 모르겠습니다.

이제 저는 모든 일인 프로젝트에 Git을 사용하고 있으며 마지막 몇 가지 작업에서도 사용했습니다.

CI는 다른 문제입니다. 가지고 다니는 것이 좋으며 권장하지만, 적어도 통역 언어로 된 소규모 프로젝트의 경우 버전 관리보다 덜 중요합니다. 그러나 최근의 대부분의 작업에는 CI 서버가있었습니다. 무엇보다도, 배포하기 전에 전체 테스트 스위트를 실행하는 것을 잊을 수있는 사람은 아무도 없습니다.

나는 여기저기서 몇 개가 있지만 대부분 소기업에 빠졌다. 내가 더 자주 보는 문제는 실제로 SCM을 가지고 있지만 많은 프로젝트가 너무 작거나 중요하지 않은 것으로 간주하는 회사입니다.