2014-10-30 16 views
5

Tôi lưu trữ với AWS có nghĩa là tôi không thể sử dụng các biến môi trường để kiểm soát việc triển khai sản xuất và dàn dựng của mình. Do đó, tôi buộc phải sử dụng các chi nhánh riêng để triển khai và tôi tự hỏi liệu có cách tiếp cận thực hành tốt nhất để bảo trì không?Sử dụng hợp nhất hoặc rebase để duy trì chi nhánh triển khai

Nếu tôi hợp nhất các thay đổi vào nhánh sản xuất, cam kết chứa cài đặt sản xuất của tôi sẽ bị mất trong lịch sử chi nhánh, khiến việc chỉnh sửa các cài đặt đó trở nên khó khăn hơn.

Tuy nhiên tôi đã đọc rằng bạn không nên sử dụng tính năng rebase trong trường hợp này vì việc này sẽ khiến việc quay lại thay đổi trở nên khó khăn hơn.

+1

Tại sao sẽ biến môi trường, ngành là cách duy nhất để phân biệt giữa các môi trường khác nhau? Bạn không thể ví dụ chuyển tùy chọn khởi động cho dịch vụ để chọn tệp cấu hình nào sẽ sử dụng? –

+0

Cảm ơn bạn đã trả lời Magnus, với AWS Elastic Beanstalk, tôi không biết cách nào để làm điều này. – pingu

+0

@pingu Nó không phải là hoàn toàn rõ ràng từ câu hỏi của bạn mà tập tin là nhận được ghi đè trong đó chi nhánh (es). Bạn có thể liệt kê một sơ đồ của một số loại (văn bản sẽ đủ). –

Trả lời

3

Bạn có thể phiên bản hai tập tin cài đặt (một cho dev và một cho prod)

Sau đó, bạn có thể để lại cho một "elasticbeanstalk/hook" kịch bản để ghi các file settting thực tế cho bạn sau một "git aws.push".

Bạn có thể xem ví dụ về sự cố tương tự trong "How to get Elastic Beanstalk nginx-backed proxy server to auto-redirect from HTTP to HTTPS?", về ứng dụng Nút (có thể không phải là trường hợp chính xác của bạn), trong đó tệp .ebextensions/config sẽ viết /opt/elasticbeanstalk/hooks/configdeploy/enact/myscript.sh.

Tập lệnh cuối cùng là một móc có thể chạy khi triển khai và có thể cập nhật tệp cấu hình thực tế của môi trường của bạn.

+0

Cảm ơn bạn đã trả lời của bạn, tôi hơi bối rối tuy nhiên, khi bạn thực hiện "git aws.push" làm thế nào để bạn xác định môi trường của bạn để móc chính xác có thể chạy? – pingu

+0

với eb push, tôi giả sử: https://forums.aws.amazon.com/ann.jspa?annID=1772 và http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-reference- branch-environment.html – VonC

+0

nhưng không chỉ định môi trường của bạn. – pingu

4

Tôi cũng phải đối mặt với nhiều thách thức để thực hiện git trong dự án mới nhất của mình. Sau quá nhiều googling tôi tìm thấy blog này và nó thực sự là một cách tốt đẹp để duy trì mô hình chi nhánh git.

A successful Git branching model enter image description here Các repo trung ương nắm giữ hai chi nhánh chính với một cuộc đời vô hạn:

  • chủ
  • phát triển

Nhánh chủ tại gốc nên quen thuộc đối với mọi người sử dụng Git. Song song với nhánh chính, một nhánh khác tồn tại được gọi là phát triển.

Chúng tôi coi origin/master là nhánh chính, nơi mã nguồn của HEAD luôn phản ánh trạng thái sẵn sàng sản xuất.

Chúng tôi xem xét nguồn gốc/phát triển làm chi nhánh chính nơi mã nguồn của HEAD luôn phản ánh trạng thái có thay đổi phát triển được phân phối mới nhất cho bản phát hành tiếp theo. Một số sẽ gọi đây là “nhánh hội nhập”. Đây là nơi mà bất kỳ xây dựng tự động hàng đêm được xây dựng từ.

chi nhánh Hỗ trợ

Các loại khác nhau của chi nhánh chúng tôi có thể sử dụng là:

  • nhánh đặc trưng
  • chi nhánh phát hành
  • Hotfix chi nhánh

nhánh đặc trưng: Các chi nhánh tính năng (hoặc đôi khi được gọi là các nhánh chủ đề) được sử dụng để phát triển các tính năng mới cho bản phát hành sắp tới hoặc tương lai xa.

thể chi nhánh ra từ: phát triển

Phải hợp lại thành: phát triển

Chi nhánh quy ước đặt tên: bất cứ điều gì ngoại trừ thuyền trưởng, phát triển, release- , hoặc hotfix-

Phát hành chi nhánh: Các chi nhánh phát hành hỗ trợ chuẩn bị bản phát hành sản phẩm mới. Chúng cho phép chấm dứt phút cuối của chữ I và chữ thập.

thể chi nhánh ra từ: phát triển

Phải hợp lại thành: phát triển và làm chủ

Chi nhánh quy ước đặt tên: release- *

chi nhánh Hotfix: chi nhánh Hotfix rất nhiều giống như các nhánh phát hành ở chỗ chúng cũng có nghĩa là chuẩn bị cho một bản phát hành sản phẩm mới, mặc dù không có kế hoạch. Chúng phát sinh từ sự cần thiết phải hành động ngay lập tức khi một trạng thái không mong muốn của một phiên bản sản xuất trực tiếp.

thể chi nhánh ra từ: chủ

Phải hợp lại thành: phát triển và làm chủ

Chi nhánh quy ước đặt tên: hotfix- *

Bạn có thể tìm thêm thông tin chi tiết về mô hình phân nhánh Git này từ blog. Các lệnh được sử dụng cho mô hình phân nhánh cũng được liệt kê trong blog. Check the blog để biết thêm chi tiết. Tôi đã triển khai thành công mô hình phân nhánh trong dự án của mình với một số thay đổi từ mô hình được đề cập trong blog. Git là một công cụ mạnh mẽ và linh hoạt, và đây chỉ là một cách để sử dụng Git.

+0

@ Damodaran- Cảm ơn bạn đã trả lời chi tiết. Nếu tôi áp dụng mô hình này cho vấn đề cụ thể của mình, tôi tưởng tượng rằng thiết lập sản xuất cụ thể của tôi sẽ nằm trên nhánh phát hành, tuy nhiên bạn nói về các nhánh phát hành "Phải hợp nhất trở lại: phát triển và làm chủ", điều này sẽ không được mong muốn cho sản xuất chỉ cài đặt. – pingu

+0

Không. Tôi sẽ làm rõ, ví dụ nếu bạn có một từ bỏ tính năng trong một nhánh. Sau khi hoàn thành nhiệm vụ, nhà phát triển đưa ra một yêu cầu kéo và bạn sẽ hợp nhất nó với việc phát triển nhánh và kiểm tra nó. Nếu có bất kỳ lỗi nào, bạn sẽ yêu cầu nhà phát triển thực hiện điều đó trong nhánh và sau khi hoàn tất, bạn hợp nhất chi nhánh để phát triển. Khi tính năng đã sẵn sàng để phát hành, bạn tạo một nhánh phát hành và hợp nhất tất cả các tính năng được thiết lập (các nhánh khác nhau) cần phải chuyển đến sống với nhánh đó và nhả nó ra. Vẻ đẹp của mô hình chi nhánh Git là bạn có thể tạo ra mô hình của riêng bạn để đáp ứng yêu cầu của bạn. – Damodaran

+0

[Tech Talk: Linus Torvalds trên git] (https://www.youtube.com/watch?v=4XpnKHJAok8) – Damodaran

2

Trên master, phiên bản cả hai tệp cài đặt (settings_mastersettings_prod) và liên kết tượng trưng settings -> settings_master. Bây giờ, chi nhánh prod tắt master (hoặc hợp nhất master vào prod nếu nó đã tồn tại) và, trong prod, chỉ sửa đổi liên kết tượng trưng settings để trỏ đến settings_prod.

Cam kết thay đổi này thành prod.

Bây giờ, hãy thực hiện tất cả phát triển trên master và miễn là bạn không tự sửa đổi liên kết tượng trưng (thay đổi tệp cài đặt), bạn có thể hợp nhất master thành prod bao nhiêu lần tùy thích mục tiêu của settings. Ứng dụng của bạn sẽ truy xuất cấu hình từ settings.

này sẽ dẫn đến một lịch sử cam kết rằng trông như thế này:

... -o---o---o---o master 
     \  \ \ 
... --o-------o---o prod 

Các diff master-prod sau mỗi lần sáp nhập master vào prod sẽ luôn luôn được chính xác:

--- a/settings 
+++ b/settings 
@@ -1 +1 @@ 
-settings_master 
\ No newline at end of file 
+settings_prod 
\ No newline at end of file 
2

Có một vài liên kết dưới đây chia sẻ một số ý kiến ​​về phương pháp luận và lý do đằng sau lý do tại sao bạn nên chọn rebase hoặc merge.

  • Hợp nhất là lý tưởng để nhập mã vào chi nhánh được chia sẻ giữa một nhóm. Vì Rebase ghi lại lịch sử của các cam kết, bối cảnh của các cam kết liên quan (như phân nhánh tính năng) bị mất do các cam kết trở thành tuyến tính dựa trên các dấu thời gian.
  • Việc rebase có thể là lý tưởng để kéo mã vào chi nhánh đang hoạt động của bạn trước khi quay trở lại nhánh chia sẻ. Kết quả tuyến tính và thay đổi lịch sử có thể dẫn đến việc hợp nhất thành công hơn các cam kết.

Xem:

Các vấn đề liên quan