Chuẩn bị kế hoạch bàn giao mã nguồn [đã đóng]


12

Công ty chúng tôi sắp có được một mã nguồn của một sản phẩm khổng lồ.

Điều gì cần xem xét khi bắt đầu bàn giao, để đảm bảo chúng tôi có mọi thứ và có khả năng duy trì sản phẩm đó trong tương lai?


1
Nếu có thể, yêu cầu mua lại cho một số kỹ sư làm việc trong dự án. Điều này sẽ giúp với vấn đề liên tục tài nguyên.
tehnyit

chúng ta không đủ may mắn chúng tôi không thể làm điều đó tối đa chúng tôi có thể làm là làm cho một số kỹ sư có sẵn trong 3-4 tuần.
Ahmed Aswani

Tôi đã tìm thấy một câu trả lời liên quan Tôi nghĩ rằng nó hoàn thành những gì hầu hết các câu trả lời ở đây.
Ahmed Aswani

Câu trả lời:


8

Đầu tiên là may mắn.

Dưới đây là một số điều mà bạn có thể nên yêu cầu / được cung cấp.

  • Danh sách các khuyết tật đã biết.
  • Danh sách các sự cố và hồ sơ vấn đề.
  • Chi tiết về hai bản phát hành cuối cùng như; Họ mất bao lâu để thực hiện, đã có một khoảng thời gian các sự cố gia tăng sau khi phát hành, v.v.
  • Các chuyên gia vấn đề chính là ai.
  • Giờ hoạt động và hỗ trợ chính là gì
  • Sản phẩm đã tồn tại được bao lâu và cơ sở mã ổn định như thế nào.
  • Lộ trình sản phẩm là gì.
  • Ngăn xếp công nghệ là gì.
  • Các điểm tích hợp là gì, và ai hỗ trợ các hệ thống tích hợp.
  • Có thành phần DR nào không
  • Ai chịu trách nhiệm gọi DR
  • SLA ứng dụng hoặc mục tiêu dịch vụ là gì.
  • Sự tăng trưởng dự kiến ​​của hàng đợi hệ thống tập tin / cơ sở dữ liệu / tin nhắn là gì.
  • Khi sao lưu hệ thống được thực hiện, ai chịu trách nhiệm và chiến lược phục hồi là gì.
  • Ai chịu trách nhiệm quản lý tồn đọng sản phẩm.
  • Những gì nhà cung cấp SLA và chi tiết liên lạc được đưa ra.
  • Có bất kỳ lịch trình hàng loạt hoặc quá trình chạy dài.
  • Là hệ thống hoàn toàn giao dịch và cách quản lý đồng thời.
  • Quy trình quản lý sự cố chính cho ứng dụng là gì.
  • Các bên liên quan đã thông báo gì về những thay đổi và ngừng hoạt động.
  • Thời gian mất điện / lần thỏa thuận là gì.
  • Mã nguồn được giữ ở đâu.
  • Làm thế nào là mã nguồn được sao lưu, khôi phục và thay đổi nhật ký được quản lý.
  • Ở đâu, cái gì và ai sở hữu kiến ​​trúc giải pháp.
  • Mục tiêu triển khai là gì (DEV, ST, UAT, Pre PROD, PROD, DR).
  • Khi giấy phép bên thứ 3 được gia hạn.
  • Có biểu đồ RACI không
  • Có bao nhiêu người dùng ở đó và họ đang ở đâu.
  • Các vấn đề hoặc khiếu nại phổ biến là gì.
  • Ai chịu trách nhiệm cấp quyền truy cập hệ thống.
  • Khi kiểm tra dồn nén / kiểm toán an ninh được thực hiện.
  • CI và quy trình xây dựng tự động ở đâu.
  • Ai chịu trách nhiệm quản lý kiểm soát nguồn và xây dựng máy chủ.
  • Hướng dẫn cài đặt ở đâu.
  • Có tài liệu cho cơ sở hạ tầng và mạng đích.
  • Các loại nghiêm trọng và tác động từ các sự cố gần đây là gì.
  • Có hướng dẫn thiết lập máy trạm phát triển.
    • Những trợ lý và khung phát triển nào được sử dụng và chúng được cấp phép cho nhóm của bạn.

Đó là tất cả những gì tôi có thể nghĩ ra vào lúc này.


8
Vui lòng xác định "DR", "DEV, ST, UAT, Pre SẢN XUẤT, SẢN XUẤT, DR" và "RACI". Lưu ý rằng một số điều này không liên quan đến mã nguồn (ví dụ: biểu đồ RACI là tổ chức, hoàn toàn không liên quan đến mã.)
S.Lott

Tôi sẽ truy cập vào kho lưu trữ mã nguồn whoel không chỉ các phiên bản hiện tại của mã nguồn teh. Các ý kiến ​​trong này thường sẽ tellyou tại sao mã được thay đổi một cách cụ thể. Đó là điều quan trọng đối với iknwo để duy trì nó.
HLGEM

@HLGEM xin lỗi tuyên bố của tôi về các phiên bản hiện tại của mã nguồn ngụ ý (dù sao với tôi cũng vậy) mã nguồn đầy đủ cho tất cả các thành phần.
Kane

@ S.Lott DR được sử dụng để mô tả "khắc phục thảm họa". Dev là một thuật ngữ chung cho "Môi trường phát triển", bất cứ điều gì bao gồm cho môi trường của bạn. ST là tên viết tắt của Hệ thống kiểm tra hệ thống. Tôi không đồng ý rằng RACI là một công cụ tổ chức vì nó được sử dụng để mô tả ai chịu trách nhiệm, chịu trách nhiệm, thông báo và tư vấn. Vậy khi mã được cam kết ai chịu trách nhiệm cho nó? Ai được tư vấn là một phần của đánh giá ngang hàng? Ai được thông báo rằng một bản dựng thành công / thất bại? Và như vậy
Kane

@kame: Vui lòng cập nhật câu trả lời với các định nghĩa. Xin vui lòng không thêm nhiều ý kiến ​​cho câu trả lời. Hãy cập nhật câu trả lời.
S.Lott

6

Điều gì cần xem xét khi bắt đầu bàn giao, để đảm bảo chúng tôi có mọi thứ và có khả năng duy trì sản phẩm đó trong tương lai?

Những điều bạn nên chắc chắn là:

  • bạn thấy họ xây dựng mã thành công
  • bạn thấy họ xây dựng các bài kiểm tra đơn vị và làm cho tất cả vượt qua
  • bạn thấy họ thực hiện các thử nghiệm khác thành công và tất cả đều vượt qua (chấp nhận, tích hợp, v.v.)
  • bạn có được cơ sở dữ liệu về các vấn đề mở (dễ dàng nhận được nếu họ sử dụng bugzilla hoặc tương tự)
  • sản phẩm chạy (hướng dẫn cài đặt).

Mọi thứ khác là tùy thuộc vào người bảo trì hiện tại để bàn giao.


2
Tôi sẽ đề nghị những cái này được sửa đổi để có dòng chữ "Bạn phải xem chúng ...", vd, "Bạn phải thấy họ xây dựng mã" và "Bạn phải thấy họ chạy thử nghiệm đơn vị", v.v ... Bằng chứng rất quan trọng ở đây.
S.Lott

@ S.Lott Cho dù họ hiển thị, hoặc viết trong một tài liệu, điều đó không thành vấn đề. Ahmed Aswani và nhóm của mình sẽ duy trì ứng dụng và có thể tự mình thực hiện tất cả các bước trên. Tôi đã sửa đổi câu trả lời một chút, nhưng tôi không chắc đó có phải là những gì bạn đề xuất không.
BЈовић

1
Một tuyên bố rằng các mã xây dựng không giống như thực sự nhìn thấy mã được xây dựng. Đã ở đó. Làm xong mà. Các tài liệu có thể mơ hồ, hoặc khó hiểu hoặc không đầy đủ. Đó là nguyên tắc "Tin tưởng nhưng Xác minh" cũ. Cho đến khi bạn nhìn thấy nó, đừng tin nó.
S.Lott

1
@ S.Lott Ok có ý nghĩa. Bây giờ tôi nghĩ về nó, tôi đã ở trong tình huống tương tự trước đây, nơi họ bắt chúng tôi thực hiện một cái gì đó trên các bảng CTNH bị hỏng. Chúng tôi đã dành 4 tháng trước khi tìm ra điều gì thực sự sai.
BЈовић

5

Bạn cần đảm bảo rằng nhóm bàn giao mã sẽ cung cấp hỗ trợ trong một khoảng thời gian. Làm cho nó một hợp đồng đã ký!

Sau này bạn sẽ có câu hỏi rằng bạn không biết bạn phải hỏi trước, vì vậy họ cần "bám sát" để giải thích cho bạn không chỉ đưa ra mã, tài liệu và bất cứ điều gì họ có trong dự án.

Khi bạn có một dự án bàn giao, bạn mất một điều quan trọng: kinh nghiệm nhóm ban đầu.

Đôi khi bạn cũng nhận được một thứ mà bạn không ngờ tới: sự thù địch của họ.

Là công ty làm việc bàn giao có được một thỏa thuận tốt với việc bàn giao? Nếu họ mất kinh doanh vì họ chuyển dự án cho bạn, các nhà phát triển (tự hào) đã tạo mã có thể phẫn nộ vì thực tế là "đứa con" của họ bị cho đi. Bạn có thể nhận được câu trả lời như: "Đó là trong các tài liệu bạn có" ... ngay cả khi không.

Các khía cạnh kỹ thuật là tốt để bao gồm, nhưng cũng xem xét khía cạnh con người của nó.

YMMV!


0

Có mã đi kèm với một bộ thử nghiệm? Làm tất cả các bài kiểm tra trong bộ thử nghiệm vượt qua? Bộ có bao nhiêu bảo hiểm?

Tôi khuyên bạn rằng, thiếu một bộ thử nghiệm, bạn nên xây dựng bộ thử nghiệm và khung liên quan ưu tiên hàng đầu của bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.