cải thiện chiến lược triển khai của chúng tôi


12

Chúng tôi có một ứng dụng thương mại điện tử mà chúng tôi phát triển tại công ty của chúng tôi. Đây là một ứng dụng LAMP tiêu chuẩn hợp lý mà chúng tôi đã phát triển trong khoảng 3 năm. Chúng tôi phát triển ứng dụng trên một miền thử nghiệm, ở đây chúng tôi thêm các tính năng mới và sửa lỗi, v.v. Theo dõi lỗi và phát triển tính năng của chúng tôi đều được quản lý trong một giải pháp lật đổ được lưu trữ (unluddle.com). Khi các lỗi được báo cáo, chúng tôi thực hiện các sửa lỗi này trên miền thử nghiệm và sau đó cam kết thay đổi đối với svn khi chúng tôi hài lòng, lỗi đã được sửa. Chúng tôi làm theo quy trình tương tự với việc bổ sung các tính năng mới.

Rất đáng để chỉ ra kiến ​​trúc chung của hệ thống và ứng dụng của chúng tôi trên các máy chủ của chúng tôi. Mỗi khi một tính năng mới được phát triển, chúng tôi sẽ cập nhật bản cập nhật này cho tất cả các trang web bằng ứng dụng của chúng tôi (luôn là máy chủ chúng tôi kiểm soát). Mỗi trang web sử dụng hệ thống của chúng tôi về cơ bản sử dụng chính xác các tệp giống nhau cho 95% cơ sở mã. Chúng tôi có một vài thư mục trong mỗi trang có chứa các tệp đặt trước cho trang đó - tệp / hình ảnh css, v.v. Khác với sự khác biệt giữa mỗi trang được xác định bởi các cài đặt cấu hình khác nhau trong mỗi cơ sở dữ liệu của trang.

Điều này nhận được vào việc triển khai thực tế chính nó. Và khi chúng tôi sẵn sàng tung ra một bản cập nhật của một số loại, chúng tôi chạy một lệnh trên máy chủ mà trang web thử nghiệm đang bật. Điều này thực hiện một lệnh sao chép (cp -fru / testsite / / otherite /) và đi qua từng lực lượng vhost cập nhật các tệp dựa trên ngày sửa đổi. Mỗi máy chủ bổ sung mà chúng tôi lưu trữ trên có một vhost mà chúng tôi đồng bộ hóa cơ sở mã sản xuất và sau đó chúng tôi lặp lại quy trình sao chép trên tất cả các trang web trên máy chủ đó. Trong quá trình này, chúng tôi chuyển các tệp mà chúng tôi không muốn ghi đè lên, di chuyển chúng trở lại khi bản sao đã hoàn thành. Kịch bản giới thiệu của chúng tôi thực hiện một số chức năng khác như áp dụng các lệnh SQL để thay đổi từng cơ sở dữ liệu, thêm các trường / bảng mới, v.v.

Chúng tôi ngày càng lo ngại rằng quy trình của chúng tôi không đủ ổn định, không chịu lỗi và cũng là một phương pháp vũ phu. Chúng tôi cũng nhận thức được rằng chúng tôi không sử dụng lật đổ tốt nhất vì chúng tôi có một vị trí làm việc trên một tính năng mới sẽ ngăn chúng tôi đưa ra một bản sửa lỗi quan trọng vì chúng tôi không sử dụng các nhánh hoặc thẻ. Có vẻ như chúng tôi đã sao chép rất nhiều tệp trên các máy chủ của mình. Chúng tôi cũng không thể dễ dàng thực hiện quay lại những gì chúng tôi vừa tung ra. Chúng tôi thực hiện một khác biệt trước mỗi lần giới thiệu để chúng tôi có thể nhận được một danh sách các tệp sẽ được thay đổi để chúng tôi biết những gì đã được thay đổi sau đó nhưng quá trình quay lại vẫn còn vấn đề. Về mặt cơ sở dữ liệu, tôi đã bắt đầu xem xét dbdeploy như một giải pháp tiềm năng. Điều chúng tôi thực sự muốn là một số hướng dẫn chung về cách chúng tôi có thể cải thiện việc quản lý và triển khai tệp của mình. Lý tưởng nhất là chúng tôi muốn quản lý tệp được liên kết chặt chẽ hơn với kho lưu trữ của chúng tôi để triển khai / rollback sẽ được kết nối nhiều hơn với svn. Một cái gì đó giống như sử dụng lệnh xuất để đảm bảo các tệp trang web giống như các tệp repo. Nó cũng sẽ là tốt mặc dù nếu giải pháp có thể cũng sẽ dừng sao chép tập tin xung quanh các máy chủ của chúng tôi.

Bỏ qua các phương pháp hiện tại của chúng tôi sẽ rất tốt khi nghe cách người khác tiếp cận vấn đề tương tự.

tóm tắt ...

  • Cách tốt nhất để làm cho các tệp trên nhiều máy chủ được đồng bộ hóa với svn là gì?
  • Làm thế nào chúng ta nên ngăn chặn sao chép tập tin? symlink / cái gì khác?
  • Làm thế nào chúng ta nên cấu trúc repo của chúng tôi để chúng tôi có thể phát triển các tính năng mới và sửa các tính năng cũ?
  • Làm thế nào chúng ta nên kích hoạt rollouts / rollback?

Cảm ơn trước

BIÊN TẬP:

Gần đây tôi đã đọc rất nhiều điều hay về việc sử dụng PhingCapistrano cho các loại nhiệm vụ này. Bất cứ ai cũng có thể cung cấp thêm thông tin về họ và họ sẽ làm tốt như thế nào cho loại nhiệm vụ này?

Câu trả lời:


6

Lời khuyên của tôi khi thực hiện các bản phát hành là có Bản phát hành tính năng và Bản phát hành bảo trì. Bản phát hành tính năng sẽ là bản phát hành có tính năng mới. Chúng được thêm vào thân cây lật đổ của bạn. Khi bạn nghĩ rằng đây là những tính năng hoàn chỉnh, bạn phân nhánh chúng thành một nhánh phát hành. Khi quy trình QA của bạn hài lòng với bản phát hành này, bạn gắn thẻ bản phát hành và triển khai mã đến các máy chủ của mình.

Bây giờ, khi bạn nhận được một báo cáo lỗi, bạn cam kết sửa lỗi này cho nhánh và chuyển nó vào trung kế. Khi bạn hài lòng với số lượng lỗi được sửa, bạn có thể gắn thẻ và triển khai Bản phát hành bảo trì.

Điều quan trọng là bạn có một nhánh của cơ sở mã sống của mình (hoặc có khả năng tạo một cơ sở bằng cách biết sửa đổi trực tiếp) tách biệt với nhánh phát triển của bạn, để bạn có khả năng triển khai các bản sửa lỗi cho mã sống của mình mà không cần phải triển khai các tính năng mới hoặc mã chưa được kiểm tra.

Tôi sẽ khuyên bạn nên sử dụng hệ thống đóng gói riêng của nhà phân phối để triển khai mã mới. Nếu bạn có một gói chứa tất cả cơ sở mã của bạn, bạn biết tất cả mã của bạn đã được triển khai trong một loại hoạt động nguyên tử, bạn có thể xem phiên bản nào được cài đặt trong nháy mắt, có thể xác minh cơ sở mã của bạn bằng cách kiểm tra các gói của bạn. Quay lại chỉ là một trường hợp cài đặt phiên bản đã cài đặt trước đó của gói.

Rào cản duy nhất tôi có thể thấy cho bạn khi thực hiện điều này là bạn dường như có nhiều bản sao của cơ sở mã cho các khách hàng khác nhau đang chạy trên một máy chủ. Tôi sẽ cố gắng sắp xếp mã của bạn để tất cả khách hàng chạy cùng một tệp và không sử dụng bản sao. Tôi không biết việc đó sẽ dễ dàng như thế nào đối với bạn, nhưng việc giảm số lượng bản sao bạn phải xử lý sẽ giúp bạn giảm đau đầu.

Tôi giả sử rằng như bạn đã đề cập đến LAMP, bạn đang sử dụng PHP hoặc ngôn ngữ kịch bản lệnh khác, không yêu cầu quá trình biên dịch. Điều này có nghĩa là bạn có thể đang bỏ lỡ một quy trình tuyệt vời có tên là Tích hợp liên tục. Điều này về cơ bản có nghĩa là mã của bạn liên tục được kiểm tra để đảm bảo mã vẫn ở trạng thái có thể tin cậy được. Mỗi khi ai đó kiểm tra mã mới, một quy trình sẽ lấy nó và chạy quy trình xây dựng và thử nghiệm. Với ngôn ngữ được biên dịch, bạn thường sử dụng ngôn ngữ này để đảm bảo mã vẫn được biên dịch. Với mọi ngôn ngữ, bạn nên tận dụng cơ hội để chạy thử nghiệm đơn vị (mã của bạn nằm trong các đơn vị thử nghiệm phải không?) Và thử nghiệm tích hợp. Đối với các trang web, một công cụ tốt để kiểm tra các bài kiểm tra tích hợp là Selenium. Trong các bản dựng Java của chúng tôi, chúng tôi cũng đo lường mức độ bao phủ mã và số liệu mã để xem cách chúng tôi tiến bộ theo thời gian. Máy chủ CI tốt nhất mà chúng tôi tìm thấy cho Java là Hudson, nhưng một cái gì đó như buildbot có thể hoạt động tốt hơn cho các ngôn ngữ khác. Bạn có thể xây dựng các gói bằng máy chủ CI của bạn.


cảm ơn. vâng, chúng tôi đang sử dụng PHP. Tôi phải thừa nhận rằng tôi không quá quan tâm đến việc tích hợp liên tục, từ những gì tôi biết nó rất giống với thử nghiệm đơn vị nhưng tôi không biết nhiều hơn thế. Chúng tôi quan tâm đến thử nghiệm đơn vị nhưng cơ sở mã của chúng tôi vẫn có rất nhiều mã thủ tục kế thừa không thực sự cho vay để thử nghiệm đơn vị. Mặc dù vậy, một số ý tưởng thú vị sẽ rất tốt khi nghe những ý tưởng bạn có về cách mã của chúng tôi có thể được tổ chức tốt hơn để ngăn chặn sự sao chép.
robjmills

tích hợp liên tục theo nghĩa đen chỉ là chạy thử nghiệm tự động trên mỗi lần đăng ký hoặc mỗi giờ hoặc mỗi ngày. Chỉ cần bạn làm điều đó thường xuyên và tự động, đó là khá nhiều CI.
David Pashley

tôi đã thấy bài viết này ngày hôm nay về việc sử dụng hudson cùng với PHP và Phing - toptopic.wordpress.com/2009/02/26/php-and-hudson
robjmills

1

Chúng tôi bắt đầu sử dụng Puppet (sản phẩm chủ lực của Reditable Labs). Nó là một khung dựa trên Ruby để tự động hóa các công việc quản trị hệ thống. Tôi đã ở múa rối vài tuần trước và đây là các liên kết video:

Luke KIST Trình bày - Giới thiệu rối

Ngoài ra, nếu bạn muốn xem tất cả các bài thuyết trình được thực hiện tại múa rối ở san francisco, thì đây là liên kết:

Bài thuyết trình về cách người khác sử dụng Con rối

Thưởng thức.

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.