Chiến lược triển khai php ưa thích của bạn là gì? [đóng cửa]

Tôi đang bắt đầu một dự án mới trong PHP và tôi rất muốn nhận được một số phản hồi từ các nhà phát triển khác về chiến lược ưa thích của họ để triển khai PHP. Tôi muốn tự động hóa mọi thứ một chút để một khi các thay đổi được cam kết, chúng có thể nhanh chóng được chuyển đến một máy chủ phát triển hoặc sản xuất.

Tôi có kinh nghiệm với việc triển khai bằng Capistrano với Ruby cũng như một số kịch bản shell cơ bản.

Trước khi tôi tự mình đi đầu tiên, thật tuyệt khi nghe người khác tiếp cận điều này như thế nào trong các dự án của họ.

Thêm thông tin

Hiện tại các nhà phát triển làm việc trên các cài đặt cục bộ của trang web và cam kết thay đổi đối với kho lưu trữ lật đổ. Việc triển khai ban đầu được thực hiện bằng cách xuất bản phát hành được gắn thẻ từ svn và tải nó lên máy chủ.

Các thay đổi bổ sung thường được thực hiện từng phần bằng cách tải lên các tệp đã thay đổi theo cách thủ công.

Đối với PHP, SVN với các tập lệnh xây dựng Phing là cách để đi. Phing tương tự như ANT nhưng được viết bằng PHP, điều này giúp các nhà phát triển PHP dễ dàng sửa đổi hơn cho nhu cầu của họ.

Thói quen triển khai của chúng tôi như sau:

• Mọi người đều phát triển trên cùng một máy chủ cục bộ tại nơi làm việc, mọi nhà phát triển đều có kiểm tra trên máy của anh ta ở nhà.
• Cam kết kích hoạt một hook post-commit cập nhật máy chủ dàn dựng.
• Các thử nghiệm được chạy trên máy chủ dàn, nếu chúng vượt qua - tiếp tục.
• Kịch bản xây dựng Phing được chạy:
• Mất máy chủ sản xuất, chuyển tên miền sang trang "Đang xây dựng"
• Chạy cập nhật SVN khi kiểm tra sản xuất
• Chạy kịch bản deltas lược đồ
• Chạy thử nghiệm
• Nếu thử nghiệm thất bại - chạy tập lệnh rollback
• Nếu kiểm tra vượt qua, máy chủ sẽ quay trở lại kiểm tra sản xuất

Ngoài ra còn có phpUnderControl , một máy chủ Tích hợp liên tục. Tôi đã không thấy nó rất hữu ích cho các dự án web thành thật.

Tôi hiện đang triển khai PHP bằng Git . Một sản phẩm đẩy git đơn giản là tất cả những gì cần thiết để cập nhật máy chủ sản xuất của tôi với bản sao mới nhất từ ​​Git. Thật dễ dàng và nhanh chóng vì Git đủ thông minh để chỉ gửi các khác biệt chứ không phải toàn bộ dự án một lần nữa. Nó cũng giúp giữ một bản sao dự phòng của kho lưu trữ trên máy chủ web trong trường hợp lỗi phần cứng của tôi (mặc dù tôi cũng đẩy GitHub để an toàn).

Chúng tôi sử dụng Webistrano , một trang web dành cho Capistrano và rất hài lòng với nó.

Webistrano cho phép triển khai nhiều giai đoạn, đa môi trường từ SVN, GIT và những người khác. Nó có hỗ trợ rollback tích hợp, hỗ trợ cho các vai trò máy chủ riêng biệt như web, db, ứng dụng, v.v. và triển khai song song. Nó cho phép bạn ghi đè các tham số cấu hình trên nhiều cấp độ, chẳng hạn như theo từng giai đoạn và ghi lại kết quả của mỗi lần triển khai, gửi thư tùy chọn.

Mặc dù Capistrano và Webistrano là các ứng dụng Ruby, cú pháp của việc triển khai 'công thức nấu ăn' đủ dễ dàng và đủ mạnh để hiểu cho bất kỳ lập trình viên PHP nào. Ban đầu Capistrano được xây dựng cho các dự án Ruby on Rails, nhưng dễ dàng chứa các dự án PHP.

Sau khi được cấu hình, nó thậm chí đủ dễ sử dụng cho những người không lập trình, chẳng hạn như người kiểm tra triển khai phiên bản dàn dựng.

Để cung cấp triển khai nhanh nhất có thể, chúng tôi đã cài đặt phương thức fast_remote_cache , cập nhật bộ đệm sao chép svn làm việc trên máy chủ từ xa, sau đó liên kết cứng kết quả.

Tôi sử dụng Apache Ant để triển khai các mục tiêu khác nhau (dev, QA và live). Ant được thiết kế để hoạt động cho việc triển khai Java, nhưng nó cung cấp một giải pháp trường hợp chung khá hữu ích để triển khai các tệp tùy ý.

Cú pháp của tệp build.xml khá dễ học - bạn xác định các mục tiêu khác nhau và các phụ thuộc của chúng chạy khi bạn gọi chương trình ant trên dòng lệnh.

Ví dụ: tôi có các mục tiêu cho dev, QA và live, mỗi mục tiêu phụ thuộc vào mục tiêu cvsbuild để kiểm tra sửa đổi đầu mới nhất từ ​​máy chủ CVS của chúng tôi, sao chép các tệp thích hợp vào thư mục bản dựng (sử dụng thẻ tập tin), sau đó rsyncs thư mục xây dựng đến máy chủ thích hợp. Có một vài điều kỳ quặc để học và đường cong học tập không hoàn toàn bằng phẳng, nhưng tôi đã làm theo cách này trong nhiều năm mà không gặp rắc rối nào nên tôi khuyên bạn nên sử dụng nó cho tình huống của bạn, mặc dù tôi tò mò không biết câu trả lời nào khác Tôi sẽ thấy trên chủ đề này.

Tôi làm công cụ thủ công bằng cách sử dụng Git. Một kho lưu trữ để phát triển, được git push --mirrorchuyển sang repo công khai và máy chủ trực tiếp là repo thứ ba được lấy từ đó. Phần này tôi cho là giống như thiết lập của riêng bạn.

Sự khác biệt lớn là tôi sử dụng các nhánh cho gần như mọi thay đổi tôi đang thực hiện (tôi đã có khoảng 5 ngay bây giờ) và có xu hướng lật qua lại giữa chúng. Chi nhánh chính không được thay đổi trực tiếp ngoại trừ việc sáp nhập các chi nhánh khác.

Tôi chạy máy chủ trực tiếp từ nhánh chính và khi tôi kết thúc với một nhánh khác và sẵn sàng hợp nhất nó, lật máy chủ sang nhánh đó một lúc. Nếu nó bị hỏng, đưa nó trở lại chủ sẽ mất vài giây. Nếu nó hoạt động, nó được hợp nhất thành chủ và mã trực tiếp được cập nhật. Tôi cho rằng một sự tương tự về điều này trong SVN sẽ có hai bản sao hoạt động và trỏ đến bản trực tiếp thông qua một liên kết tượng trưng.

Tôi biết Phing đã được nhắc đến một vài lần, nhưng tôi đã rất may mắn với phpUnderControl . Đối với chúng tôi, chúng tôi

1. Kiểm tra các bản sao riêng lẻ của các chi nhánh cho máy cục bộ
2. Các chi nhánh được kiểm tra và sau đó sáp nhập vào Trunk
3. Cam kết Trunk được xây dựng tự động bởi phpUnderControl, chạy thử nghiệm và xây dựng tất cả tài liệu, áp dụng deltas cơ sở dữ liệu
4. Trunk được chạy qua kiểm tra chất lượng và sau đó sáp nhập vào chi nhánh Ổn định của chúng tôi
5. Một lần nữa, phpUnderControl tự động xây dựng Ổn định, chạy thử nghiệm và tạo cơ sở dữ liệu cập nhật và thông tin
6. Khi chúng tôi sẵn sàng đẩy mạnh sản xuất, chúng tôi sẽ chạy tập lệnh rsync sao lưu Sản xuất, cập nhật cơ sở dữ liệu và sau đó đẩy các tệp lên. Lệnh rsync được gọi bằng tay để chúng tôi đảm bảo ai đó đang xem chương trình khuyến mãi.

một giải pháp thay thế cho các kịch bản triển khai được thực hiện tại nhà là triển khai lên một nền tảng như một dịch vụ trừu tượng hóa rất nhiều công việc đó cho bạn. Một PaaS thường sẽ cung cấp công cụ triển khai mã riêng, cũng như mở rộng quy mô, khả năng chịu lỗi (ví dụ: không bị hỏng khi phần cứng bị lỗi) và thường là một bộ công cụ tuyệt vời để theo dõi, kiểm tra nhật ký, v.v. biết cấu hình tốt sẽ được cập nhật theo thời gian (một ít đau đầu cho bạn).

PaaS tôi muốn giới thiệu là dotCloud , ngoài PHP ( xem phần khởi động PHP của họ ), nó cũng có thể triển khai MySQL, MongoDB và một loạt các dịch vụ bổ sung. Nó cũng có các tính năng tốt như triển khai không thời gian chết, khôi phục tức thì, hỗ trợ đầy đủ cho SSL và websocket, v.v. Và có một cấp miễn phí luôn luôn tốt đẹp :)

Tất nhiên tôi hơi thiên vị kể từ khi tôi làm việc ở đó! Các tùy chọn khác đáng để kiểm tra ngoài dotCloud là Pagodabox và Dàn nhạc (hiện là một phần của Engine Yard).

Hi vọng điêu nay co ich!

Sa-lô-môn

Rằng bạn tự động và mù quáng thực hiện các thay đổi từ kho lưu trữ đến các máy chủ sản xuất nghe có vẻ nguy hiểm. Điều gì xảy ra nếu mã cam kết của bạn có lỗi hồi quy, vì vậy ứng dụng sản xuất của bạn bị trục trặc?

Nhưng, nếu bạn muốn có một hệ thống Tích hợp liên tục cho PHP, tôi đoán Phing là lựa chọn tốt nhất cho PHP. Mặc dù vậy, tôi đã không tự mình kiểm tra nó khi tôi thực hiện theo cách thủ công, ví dụ như scp.

Tôi đến bữa tiệc muộn, nhưng tôi nghĩ tôi sẽ chia sẻ phương pháp của chúng tôi. Chúng tôi sử dụng Phing với Phingistrano , cung cấp chức năng giống Capistrano cho Phing thông qua các tệp xây dựng được xây dựng trước. Nó rất tuyệt, nhưng chỉ hoạt động nếu bạn sử dụng Git vào lúc này.

Tôi có một bản sao làm việc của một chi nhánh phát hành SVN trên máy chủ. Cập nhật trang web (khi không có thay đổi lược đồ) cũng dễ như ban hành lệnh cập nhật SVN. Tôi thậm chí không phải lấy trang web ngoại tuyến.

Phing có lẽ là lựa chọn tốt nhất của bạn, nếu bạn có thể chịu đựng nỗi đau của các tệp cấu hình xml. Khung Symfony có cổng cào riêng (pake), hoạt động khá tốt, nhưng được kết hợp chặt chẽ với phần còn lại của Symfony (Mặc dù bạn có thể tách chúng ra).

Một lựa chọn khác là sử dụng Capistrano. Rõ ràng là nó không tích hợp tốt với PHP, cũng như với Ruby, nhưng bạn vẫn có thể sử dụng nó cho nhiều thứ.

Cuối cùng, bạn luôn có thể viết các kịch bản shell. Cho đến nay, đó là những gì tôi đã làm.

http://controltier.org/wiki/Main_Page

chúng tôi sẽ sử dụng nó để triển khai và bảo trì nhiều máy chủ.

Một năm muộn nhưng ... Trong trường hợp của tôi, việc triển khai không tự động. Tôi thấy nguy hiểm khi triển khai mã và chạy các kịch bản di chuyển cơ sở dữ liệu tự động.

Thay vào đó, hook subversion được sử dụng để triển khai chỉ để thử nghiệm / dàn máy chủ. Mã được triển khai để sản xuất vào cuối vòng lặp, sau khi chạy thử nghiệm và đảm bảo mọi thứ sẽ hoạt động. Để tự triển khai, tôi sử dụng Makefile tùy chỉnh sử dụng rsync để truyền tệp. Makefile cũng có thể chạy các tập lệnh di chuyển trên máy chủ từ xa, tạm dừng / tiếp tục máy chủ cơ sở dữ liệu và web.

Trong công việc của tôi, bản thân tôi và nhóm của tôi đã phát triển một sự thay thế theo định hướng Phing cho việc triển khai capistrano và chúng tôi cũng đã kết hợp một số tính năng có sẵn trong phing như thử nghiệm PHPUnit, phpcs và PHPDocumentor. Chúng tôi đã làm cho nó một repo git có thể được thêm vào một dự án như là một mô hình con trong git và nó hoạt động rất tốt. Tôi đã gắn nó với một số dự án và nó đủ mô đun để dễ dàng làm cho nó hoạt động với bất kỳ dự án nào trên bất kỳ môi trường nào của chúng tôi (dàn dựng, thử nghiệm, sản xuất, v.v.).

Với các tập lệnh xây dựng phing, bạn có thể chạy chúng từ dòng lệnh một cách thủ công và tôi cũng đã thành công trong việc tự động hóa các thói quen xây dựng / triển khai với Hudson và giờ là Jenkins ci.

Tôi không thể đăng bất kỳ liên kết nào ngay bây giờ vì repo chưa được công khai, nhưng tôi được thông báo rằng chúng tôi sẽ sớm mở nguồn, vì vậy xin vui lòng liên hệ với tôi nếu bạn quan tâm hoặc nếu bạn có bất kỳ câu hỏi về tự động hóa triển khai của bạn với phing và git.

Tôi đoán cách triển khai SVN không tốt lắm. Bởi vì:

Bạn cần mở quyền truy cập SVN cho toàn thế giới

có nhiều .svn trong các máy chủ web sản xuất

Tôi nghĩ Phing tạo ra một nhánh + kết hợp tất cả js / css + thay thế giai đoạn config + ssh tải lên tất cả các máy chủ www là cách tốt hơn.

ssh đến 10 máy chủ www và svn lên cũng gặp sự cố.