Tại sao các công ty tài chính / bảo hiểm lớn nên sử dụng git và / hoặc github

Tôi làm việc cho một doanh nghiệp lớn (30K nhân viên) trong ngành tài chính / bảo hiểm. Mặc dù "CNTT" không phải là trọng tâm chính của chúng tôi, nhưng hãy trung thực, đây là những ngành công nghiệp thông tin và các công ty có lợi thế công nghệ tốt hơn dường như tiến lên nhanh hơn.

Có nhiều nhóm phát triển phần mềm tại công ty của tôi. Tất cả đều trên bản đồ với kiểm soát phiên bản, nói gì đến ngôn ngữ / khung được sử dụng. Một số không sử dụng bất kỳ (tôi biết), một số sử dụng PVCS, một số sử dụng VSS và sử dụng SVN được khai sáng nhất.

Tôi muốn mang git đến doanh nghiệp của tôi. Cụ thể hơn, tôi muốn mang GitHub (kho riêng). Tôi biết đúng người để nói về vấn đề này, nhưng hãy thành thật một lần nữa, những động thái quyết liệt như thế này thường bị bắn hạ trong bối cảnh doanh nghiệp lớn vì những lo ngại bảo mật mơ hồ hoặc thực tế là không ai trong số các đối thủ của chúng tôi đang sử dụng nó (và tôi có thể chỉ trích dẫn jQuery, Ruby on Rails, Facebook, v.v. làm tài liệu tham khảo).

Vì vậy, câu hỏi của tôi là này. Những lý do thuyết phục nhất về lý do tại sao một doanh nghiệp lớn nên từ từ và cố tình chuyển từ PVCS / VSS / SVN sang một giải pháp git được lưu trữ như GitHub (repo riêng). Tất nhiên, một phần trong kế hoạch của tôi liên quan đến POC cho một dự án phát triển không thiết yếu.

Có một vài điều tôi có thể quan tâm, như một bên thứ ba không quan tâm. Vì vậy, hãy để tôi ném cho bạn một số câu hỏi mà bạn nên chuẩn bị để trả lời (cho bộ phận CNTT của bạn):

• Bất kỳ phiên bản kiểm soát nào là tốt hơn không có. Chúng ta có nhiều lựa chọn, có gì sai với những thứ đó?
• Kiểm soát phiên bản phân phối? Cái gì vậy Làm thế nào để chúng ta kiểm soát điều đó?
• Nó có giá bao nhiêu? Không chỉ phần mềm, mà cả máy chủ, giấy phép, bảo trì, v.v.
• Tôi không tin tưởng GitHub hoặc bất kỳ dịch vụ lưu trữ thuê ngoài nào . Chúng tôi cần phải làm mọi thứ trong nhà. Tại sao chúng ta không thể thiết lập máy chủ của riêng mình?
• Chúng ta có thể chạy nó trên Windows không? Chúng tôi phải giữ nó trên đường cơ sở hiện tại của chúng tôi, bạn biết.
• Làm thế nào để chúng ta bảo đảm điều? SVN chúng tôi nhận được, nhưng điều này làm tôi sợ.

Đây là những câu hỏi đầu tiên sẽ xuất hiện. Đối với VSS và PVCS, bạn có thể đưa ra một loạt các đối số hợp lý tốt (như lịch sử phiên bản hỏng của VSS). SVN sẽ khó khăn hơn một chút. Tôi đặc biệt khuyên bạn nên tập trung vào các khả năng hợp nhất của GIT và cũng khuyên bạn nên giữ một quan điểm cởi mở về Mercurial. Mọi đối số cho GIT cũng là một đối số cho Mercurial - và Mercurial có hỗ trợ Windows trưởng thành hơn.

An ninh là rất quan trọng đối với các tổ chức tài chính và chính phủ. Họ sẽ cực kỳ chống lại các tài nguyên được lưu trữ bên ngoài. Từ góc độ quản lý rủi ro, hãy xem xét những gì có thể xảy ra nếu ai đó hack GitHub và đánh cắp mã nguồn hoặc phát hiện ra lỗ hổng bảo mật được ghi lại trong trình theo dõi vấn đề. Điều đó sẽ tàn phá cho công ty. Từ góc độ quản lý thuần túy, nếu công ty hợp phápbắt buộc phải trả tiền cho bạn mỗi giờ bạn làm việc, làm thế nào họ có thể theo dõi xem bạn có làm việc ở nhà không khi tài nguyên nằm ngoài mạng VPN của họ? Một lưu ý khác, làm thế nào họ có thể ngăn bạn thực hiện một số hoạt động gián điệp của công ty khi tất cả các nguồn lực có sẵn từ bên ngoài công ty? Đây là các đối số CNTT và quản lý chống lại việc thuê ngoài dịch vụ lưu trữ. Một công ty lớn có nhìn vào những thứ theo cách này. Đối với một công ty nhỏ, bạn nhìn vào điểm mấu chốt và chi phí bao nhiêu để đặt tất cả các dịch vụ đó vào vị trí.

Nó thực sự rẻ hơn cho công ty lớn để làm điều đó trong nhà. Họ đã có tài nguyên CNTT, họ chỉ cần xáo trộn trách nhiệm một chút. Và nếu giải pháp chủ yếu chăm sóc bản thân chỉ với bảo trì định kỳ cần thiết (sao lưu và quản lý người dùng), thì tất cả lý do để giữ nó bên trong cửa công ty.

Đối với lưu trữ Windows, đó là một tổ chức do vấn đề tổ chức. Một số công ty đã nuốt Windows koolaid. Những người khác đã nuốt Linux koolaid. Những người khác xem xét nó trên cơ sở từng trường hợp. Bạn sẽ phải chơi theo các quy tắc mà bộ phận CNTT đã đặt ra cho tổ chức của bạn. Miễn là giải pháp của bạn có thể được lưu trữ trên một trong hai, bạn là vàng.

Cuối cùng, trong một tổ chức lớn như vậy , được đảm bảo là những người sợ tất cả muốn làm mọi thứ theo cách của họ. Tất cả họ đều có lý lẽ thuyết phục tại sao họ chọn VSS, PVCS, SVN hoặc những gì có bạn. Đối với CNTT họ đều giống nhau. Cách duy nhất để hợp nhất trong một tổ chức lớn là có lệnh đến từ fiat từ trên cao. Các đơn đặt hàng như vậy luôn gặp phải sự kháng cự và có lẽ đó không phải là điều mà công ty của bạn muốn làm trừ khi có lợi ích Tổng chi phí sở hữu (TCO) rõ ràng để có hệ thống kiểm soát phiên bản tiêu chuẩn.

Tôi cũng làm việc tại một doanh nghiệp tài chính / bảo hiểm (mặc dù không lớn như doanh nghiệp bạn hiện đang làm việc). Chúng tôi cũng có nhiều nhóm phát triển và trong khi doanh nghiệp đã chọn các sản phẩm microsoft cụ thể để phát triển thì vẫn không có kiến ​​trúc chính, ngôn ngữ hoặc kiểm soát nguồn. Tất cả chúng ta đều sử dụng .Net, nhưng chúng tôi có nhiều dự án trong các phiên bản khác nhau của khung và bằng các ngôn ngữ khác nhau. Một số dự án sử dụng VSS khác TFS. Hiện tại chúng tôi có một kiến ​​trúc sư cấp cao mới là người quản lý QA và anh ấy đã dẫn đầu một quá trình chuyển đổi doanh nghiệp nhiều hơn từ theo dõi lỗi, kiểm soát nguồn, sử dụng khung thành triển khai TFS phổ quát hơn cho tất cả. Điều này chỉ được thực hiện bởi thực tế rằng anh ta là một) cực kỳ có kinh nghiệm về bản chất của phần mềm,

Để giải quyết vấn đề này trong chính tổ chức của bạn, bạn phải xem xét một số điều trước tiên:

1. Tại sao bạn lại say mê với GitHub như câu trả lời? Bạn đang tìm kiếm kiểm soát nguồn chung hoặc bạn đang tìm kiếm một lý do để thực hiện một cái gì đó bạn cảm thấy thoải mái? Tôi không biết câu trả lời (và thẳng thắn không quan tâm), nhưng đây là một câu hỏi sẽ xuất hiện khi bạn bắt đầu làm quen với công việc của người khác.
2. Bạn hiện đang liên kết với một trong những nhóm phần mềm này? Nếu có, bạn có thể cần tìm một cá nhân không bị ảnh hưởng, có vị trí tốt để bảo vệ khái niệm này. Nếu không, các nhóm phát triển khác có thể chỉ cảm thấy bạn đang cố gắng khắc sâu suy nghĩ của bạn về họ. Điều này sẽ làm cho họ thậm chí chống lại khái niệm này nhiều hơn vì họ đã có một cái gì đó hoạt động (theo ý kiến ​​của họ).
3. Bạn đã thực hiện bất kỳ tiếp cận với các cá nhân trong các nhóm khác để mua vào khái niệm này chưa? Là các nhà phát triển khác có ý kiến ​​hoặc mối quan tâm tương tự? Một cách khác để hoàn thành nó là xây dựng một khối quan trọng theo sau trong số những người thực hiện công việc. Khi nhiều người bắt đầu yêu cầu kho lưu trữ nguồn chung, quản lý sẽ phải chú ý.
4. Bạn có đủ quen thuộc với mã / quy trình / yêu cầu của các nhóm khác đủ để nói rằng GitHub sẽ (hoặc sẽ không) làm việc cho họ không?

Đối với câu hỏi cuối cùng (hoặc thực tế?) Của bạn, lý do thuyết phục duy nhất trong dài hạn theo quan điểm của các nhà quản lý doanh nghiệp là nó tiết kiệm tiền. Các khoản tiết kiệm này có thể ở dạng giảm thời gian chết, tăng bảo mật mã, tăng năng suất của nhà phát triển, tăng dự phòng cơ sở mã (để sao lưu), v.v., et al. Điều cuối cùng bạn cần làm là thuyết phục các cá nhân viết séc cho tất cả những điều này rằng thời gian, công sức và tiền bạc để chuyển sang một mô hình như vậy cuối cùng sẽ xứng đáng với lợi tức đầu tư của họ. Bạn cũng sẽ cần phải chứng minh rằng sự hỗ trợ trong tương lai cho mô hình tương tự sẽ ở đó khi "chậm và cố tình" cuối cùng đã xảy ra.

Có rất nhiều điều đi vào sự thay đổi trong học thuyết như vậy, vì vậy sẽ cần rất nhiều sự nhiệt tình theo phong cách cơ sở và bạn chắc chắn sẽ cần một người ở cấp VP để bảo vệ khái niệm này. Một người quản lý có thể làm việc, nhưng một giám đốc điều hành sẽ có nhiều quyền hơn để in các khái niệm lên các nhóm khác.

Các công ty như vậy sẽ muốn có kho lưu trữ của họ tập trung. SVN, VSS quảng cáo PVCS có một điểm chung - tất cả chúng đều là kiến ​​trúc máy khách-máy chủ. Git được thiết kế dưới dạng VCS phân tán và về bản chất là phi tập trung.

GitHub - thậm chí còn có vấn đề hơn. Đó là một dịch vụ bên ngoài. Mã nguồn trong dịch vụ bên ngoài là thứ mà quản lý rất có thể sẽ không bao giờ chấp nhận.

Tuy nhiên, có giải pháp có thể giữ cho cả hai bên hài lòng. Git có git-svnlệnh. Về cơ bản, bạn có kho lưu trữ SVN, nhưng một số nhà phát triển có thể chọn có kho lưu trữ GIT cục bộ của riêng họ và đồng bộ hóa nó với kho lưu trữ SVN tập trung. Tốt thay thế cho các chi nhánh tư nhân hoặc gửi xung quanh các bản vá không được cam kết. Cách tốt để tích hợp git-svn .

Một vài trong số những câu trả lời này đã lỗi thời đáng kể liên quan đến các bình luận về GitHub và bảo mật vì những thay đổi tại GitHub kể từ khi chúng được đăng.

• GitHub không buộc bạn phải được lưu trữ bên ngoài
• Các miễn phí phiên bản của GitHub là gì đặt hạn chế này tại chỗ.
• Có một phiên bản doanh nghiệp của GitHub dành cho lưu trữ nội bộ . https://enterprise.github.com/home . Nó không miễn phí và chi phí $ tất nhiên

Công ty tôi làm việc chỉ mới bắt đầu sử dụng nó và chúng tôi có những mối quan tâm CHÍNH XÁC vì mã của chúng tôi là một bí mật thương mại, chúng tôi làm trong lĩnh vực tài chính. Ngoài ra, có những cách khác để sử dụng GIT không liên quan đến GitHub tương tự, redmine, gitosis, v.v ...

Liên quan đến câu hỏi "ai đang sử dụng nó": PayPal, Etsy, rackspace, vimeo, SAP, NASA của JPL , Linux Kernel

Lý do kỹ thuật thuyết phục là quá nhiều để liệt kê. Điều duy nhất đáng tập trung ở đây là các vấn đề doanh nghiệp lớn hơn ở cấp độ cao mà các câu trả lời khác chỉ ra. Cái lớn nhất tôi có thể nghĩ đến là tính nhất quán, tính đồng nhất, kiểm toán rõ ràng, đơn giản của kiểm toán. Mặc dù việc giải quyết một kho vấn đề với nhiều hệ thống VCS khác là một vấn đề lớn.

Có sự giảm bớt nỗ lực trùng lặp cho tất cả các bộ phận phải viết các kịch bản lập dị khác nhau để tích hợp giữa các hệ thống khác nhau, để kiểm tra chúng và báo cáo về chúng và kiểm soát chúng.

• Mỗi khi tôi phải sử dụng SVN trong một môi trường hoang tưởng như một công ty thương mại, các móc nối 'tuân thủ' và 'bảo mật' vô lý đã vô cùng bất lợi cho hiệu suất.

Vì tôi đã đề cập đến các vấn đề sử dụng kỹ thuật từ một nhà phát triển tiềm năng, tôi sẽ nói điều này. Với hơn 15 năm sử dụng, tôi đã sử dụng CVS, SVN, CMVC, thiết bị xóa, lực lượng và các hệ thống khác trong một môi trường chuyên nghiệp cùng với GIT. Nếu ai đó muốn tôi sử dụng thứ gì đó không phải là GIT (ngoại trừ bzr, mercurial, perforce và Clearcase (tùy thuộc vào thiết lập của hai cái cuối cùng)) tôi sẽ biết ngay thời gian của mình tốt hơn ở nơi khác. Tôi gần như đã đi đến kết luận đó (mặc dù đã gia hạn một khoản trợ cấp nhỏ cho CVS và SVN) vào năm 2009. Tôi đã quá chán ngán với cách sử dụng SVN tại nơi làm việc của mình, tôi đã bắt đầu sử dụng GIT làm khách hàng SVN của mình vào đầu năm 2010 trước đó giúp thuyết phục chúng tôi thay đổi sang GIT.