Làm thế nào chúng ta có thể theo dõi phiên bản mã nào trong mỗi môi trường?


14

Nhóm của tôi hiện đang sử dụng quy trình triển khai / phân nhánh khá đơn giản giống như sau:

                ┌────────┐ ┌────┐ ┌──────┐
 Environments:  │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Builds:        │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Branches:      │ master │ │ qa │ │ prod │
                └────────┘ └────┘ └──────┘

Mỗi môi trường có nhánh riêng (chúng tôi sử dụng git ) và bản dựng riêng sử dụng nhánh đó. Khi chúng tôi muốn quảng bá từ môi trường này sang môi trường khác, ví dụ, từ DEV sang QA, chúng tôi hợp nhất masterchi nhánh vào qavà khởi động một bản dựng QA mới (sau đó được tự động triển khai vào môi trường QA).

Chúng tôi đang xem xét chuyển sang một quy trình mới sẽ loại bỏ việc có một nhánh chuyên dụng và xây dựng cho từng môi trường. Thay vào đó, một bản phát hành duy nhất sẽ tạo ra một "gói triển khai" mà sau đó có thể được triển khai cho bất kỳ môi trường nào. Chúng tôi đang tưởng tượng một quy trình công việc điển hình sẽ trông giống như thế này:

                ┌────────┐     ┌────┐     ┌──────┐
 Environments:  │  DEV   │ ──► │ QA │ ──► │ PROD │
                └────────┘     └────┘     └──────┘

                      ▲ 
                       \ 

                        ┌───────────────┐
 Builds:                │ release build │
                        └───────────────┘

                                ▲
                                │

                ┌────────┐ ┌─────────┐
 Branches:      │ master │ │ release │
                └────────┘ └─────────┘

Quảng bá từ môi trường này sang môi trường khác sẽ không còn được xử lý trong kiểm soát nguồn; thay vào đó, chúng tôi chỉ lấy các nhị phân đã được xây dựng ("gói triển khai") và thả nó vào môi trường mới.

Hệ thống mới này sẽ cho phép chúng tôi triển khai bất kỳ bản dựng nào cho bất kỳ môi trường nào, có một số lợi thế. Ví dụ, việc kiểm tra sửa lỗi lỗi trong DEV và QA là chuyện nhỏ. Hệ thống hiện tại của chúng tôi không cung cấp một cách dễ dàng để làm điều này mà không cần quay lại một chi nhánh, điều mà rõ ràng chúng tôi muốn tránh.

Hạn chế lớn nhất với hệ thống mới này là chúng tôi không còn có cách tự động theo dõi mã nào trong môi trường nào. Nếu chúng ta cần sửa lỗi trong SẢN XUẤT, chúng ta không còn có một nhánh chuyên dụng đồng bộ với cơ sở sản xuất hiện tại. Điều tương tự cũng xảy ra với QA - nếu chúng ta muốn thúc đẩy thay đổi nhanh chóng thành QA mà không cần nạo vét công việc đang tiến hành master, chúng ta không còn có một chi nhánh phản ánh tình trạng hiện tại của môi trường QA.

Làm thế nào chúng ta có thể theo dõi mã nào trong mỗi môi trường?

Một số tùy chọn chúng tôi đang xem xét:

  • sử dụng thẻ git để theo dõi cam kết nào trong môi trường nào
  • nhúng cam kết git được sử dụng bởi bản dựng vào mỗi gói triển khai

Bạn có hệ thống CI như Hudson hay Jenkins không? Nó có khả năng đẩy các thẻ của những gì nó được xây dựng lại thành git không? (Tôi biết có những plugin cho Hudson và Jenkins có thể ... - không chắc chắn về những người khác).

@MichaelT Chúng tôi sử dụng MSBuild cho các bản dựng và Triển khai Bạch tuộc của chúng tôi để triển khai. Tôi khá tự tin rằng chúng ta có thể khiến Octopus thao túng kho git của chúng ta bằng một kịch bản triển khai Powershell tùy chỉnh.
Bạn bè của Nathan

Câu trả lời:


14

Thẻ Git là những gì bạn thực sự muốn sử dụng để chỉ định phát hành. Lý do là chúng có ý nghĩa với bạn và có thể được sử dụng để nhanh chóng nhận ra mối liên kết giữa mã được triển khai của nhà nước và bất kỳ thông tin nào mà máy chủ bản dựng có thể có (chẳng hạn như số bản dựng).

Trong khi đó là câu trả lời bạn đang tìm kiếm, nó chỉ giải quyết được một nửa vấn đề. Cái còn lại là "này, đây là triển khai .[wje]artrên máy chủ, nó được xây dựng từ đâu?" Chúng tôi biết rằng bạn sẽ không bao giờ có các phiên bản khác nhau của ứng dụng được triển khai trên dev và qa hoặc prod. Đúng?

Giải pháp cho phần đó của câu hỏi là để máy chủ xây dựng đưa thông tin vào bảng kê khai. Đến từ một ví dụ maven và svn mà tôi có trước mặt:

<manifestEntries>
    <Specification-Title>${project.name}</Specification-Title>
    <Specification-Version>${project.version}</Specification-Version>
    <Build-Number>${build.number}</Build-Number>
    <Build-Id>${build.id}</Build-Id>
    <Svn-Revison>${svn.revision}</Svn-Revison>
</manifestEntries>

Đó là trong cấu hình lưu trữ maven-war-plugin. Nhưng bạn cũng có thể tìm thấy nó trong các plugin khác. Sau đó, ở Hudson, một phần của lời mời xây dựng maven là:

-Dbuild.number=${BUILD_NUMBER}
-Dsvn.revision=${SVN_REVISION}
-Dbuild.id=${BUILD_ID}

trong đó thiết lập những định nghĩa mà sau đó maven chọn. Và sau đó chỉ là vấn đề tìm kiếm trong tệp MANIFEST.MF đã được triển khai trên máy chủ để xem phiên bản đó là gì.

Có một plugin git , cung cấp một tập hợp các biến môi trường tương tự bao gồm:

  • GIT_COMMIT - SHA của hiện tại
  • GIT_BRANCH - Tên của kho lưu trữ từ xa (mặc định là gốc), theo sau là tên của chi nhánh hiện đang được sử dụng, ví dụ: "origin / master" hoặc "origin / foo"

Sự kết hợp của hai thực tiễn này cho phép bạn dễ dàng xác định bản dựng (vì số bản dựng đi về phía trước và có ý nghĩa, không giống như tổng kiểm tra sha) và cam kết cụ thể mà nó được xây dựng từ đó.


3

Một cách tiếp cận hoàn toàn khác sẽ là loại bỏ ý tưởng versionshoàn toàn. Bạn chỉ có "một phiên bản" có hành vi cấu hình khác nhau. Sự khác biệt duy nhất là, bạn có một cơ sở mã chung - ngay cả trong sản xuất, bạn sẽ triển khai công việc đang tiến hành : nhưng không được kích hoạt.

Sự khác biệt chỉ làm giảm các bộ tính năng khác nhau được kích hoạt trong sản phẩm của bạn.

Việc hủy kích hoạt được thực hiện thông qua các tính năng bật tắt .

Ưu điểm: toàn bộ quá trình phát hành được đơn giản hóa: Bạn luôn cung cấp phiên bản tích hợp của phần mềm. Mỗi tính năng luôn có sẵn trong master. Không có chi nhánh bổ sung là cần thiết.

Không có đau đớn với các tính năng hợp nhất với nhau, bởi vì: không có chi nhánh không cần sáp nhập. Không có sự nhầm lẫn về tính năng nào trên nhánh nào và có thể phụ thuộc hoặc xung đột với các tính năng từ các nhánh khác. Mỗi phần có thể được kích hoạt theo ý muốn. Ngay cả một rollback không còn cần thiết nữa: nó chỉ là một công tắc .

Tôi không biết, nếu điều đó hoạt động cho cơ sở mã của bạn: các điều kiện tiên quyết về chất lượng mã và kỷ luật nhà phát triển khá cao - bạn phải xử lý "dọn dẹp" sau khi một tính năng trở thành chức năng cốt lõi và bạn phải quản lý một loạt các toggles ngăn chặn một mớ hỗn độn lớn hơn .

Có lẽ nó làm việc cho bạn.


Nhưng những gì về việc có các trạng thái kho lưu trữ khác nhau được triển khai cho các máy chủ khác nhau? Có phải mã đang chạy trên hộp QA giống như mã đang chạy trên sản xuất để có thể tái tạo lỗi không? Mã mà các nhà phát triển đã đẩy vào hộp nhà phát triển của họ có giống với mã mà QA đang chạy không?

1
Câu hỏi phải được đặt ra khác nhau: lỗi có cấu hình đặc biệt có thể tái tạo "ngay bây giờ" nếu có, bạn có thể sửa nó. Nếu không - lỗi có vấn đề? Bạn luôn luôn làm việc (và mã tích hợp).
Thomas Junk

-1

Chúng tôi sử dụng maven để đưa phiên bản vào tệp kê khai. Sau đó, ứng dụng sẽ hiển thị phiên bản nếu là ứng dụng web hoặc có điểm cuối / phiên bản cho các dịch vụ web.

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.