Quy trình làm việc Git + Drupal

Question

Tôi là người mới bắt đầu Git với các câu hỏi về quy trình làm việc. Tôi đã học được rất nhiều câu lệnh, và tôi biết mọi thứ hoạt động như thế nào, nhưng tôi dường như không thể tìm ra được quy trình làm việc đúng. Thích có một số gợi ý. [Lưu ý, tôi là các nhà phát triển chỉ làm việc trên các dự án của tôi]

1. Một người bạn từng nói với tôi rằng đó là tốt nhất để làm việc trên các máy chủ trực tiếp đúng hơn là trên localhost để tránh chạy vào các vấn đề cụ thể môi trường. Điều này đúng không?

2. Tôi sử dụng cùng một chủ đề cơ sở cho tất cả các trang web Drupal của mình. Khi tôi thực hiện thay đổi, tôi hiện cần sao chép và dán nó vào khoảng 10 địa điểm khác. Có cách nào giữ chủ đề cơ bản này ở một nơi và có các trang web khác vẽ từ nó không? Github có lẽ?

3. Nếu tôi muốn sao lưu 'hoàn chỉnh' của cơ sở dữ liệu và cơ sở dữ liệu - cách duy nhất để làm điều này là xuất cơ sở dữ liệu dưới dạng tệp sql và cam kết toàn bộ?

Cảm ơn sự trợ giúp!

Terry

Answer 1

1. Nói chung, bạn nên chạy thử nghiệm trên một máy chủ càng gần đến máy chủ sản xuất càng tốt, nhưng không phải là máy chủ sống thực tế, làm như thế sẽ phá vỡ một trang web hoạt động trong thử nghiệm. Bởi vì Drupal được thiết kế để chạy tốt trên nhiều máy chủ khác nhau, nên việc sử dụng các máy chủ tương tự không có liên quan.

2. Bạn nên sử dụng git pull thay vì sao chép-dán. Vì git có thiết kế phi tập trung, bạn không thực sự cần một vị trí trung tâm như github. Nếu điều đó hữu ích cho quy trình làm việc của bạn, hãy sử dụng nó, nhưng nếu không, bạn có thể kéo trực tiếp từ máy chủ này sang máy chủ khác.

3. Không có giải pháp tuyệt vời nào để Drupal lưu trữ nhiều thông tin cấu hình trong cơ sở dữ liệu và đồng bộ hóa thông tin đó. Đồng bộ hóa toàn bộ cơ sở dữ liệu của bạn là một cách tiếp cận. Nhiều mô-đun cũng có exportables, về cơ bản lưu dữ liệu từ cơ sở dữ liệu vào mã để bạn có thể đồng bộ hóa nó cùng với phần còn lại của mã của bạn. Features có lẽ là cách đơn giản nhất để thử nghiệm với mô hình có thể xuất và xem liệu mô hình đó có phù hợp với bạn hay không.

Answer 2

1. Tôi hiểu quan điểm của người bạn, nhưng tôi tin chắc không đồng ý với chạy (có khả năng, err, có lẽ) bị phá vỡ đang phát triển trên một máy chủ sản xuất. Tốt hơn, hãy tải xuống VirtualBox và thiết lập một máy ảo có cùng cấu hình với máy chủ mà bạn triển khai. Sử dụng git để tạo "thẻ" cho mỗi phiên bản bạn triển khai để bạn có các điểm tham chiếu hữu ích cho "phiên bản" của trang web của bạn.
2. Xem "git submodules". Bạn gần như chắc chắn cần phải tìm hiểu những gì đang có, nhưng nếu bạn đã đến từ một nền tảng lật đổ bạn sẽ có thể tìm thấy chúng rất khó hiểu. Submodules về cơ bản là tham chiếu đến các kho lưu trữ khác, vì vậy bạn có một liên kết mềm đến một dự án khác bên trong dự án chính của bạn. Họ phải được tự chứa trong một thư mục tuy nhiên. Cá nhân tôi muốn giữ một tệp schema.sql trong kho lưu trữ của tôi (chỉ một lược đồ trống, được viết bằng SQL) nhưng tôi không nghĩ rằng việc sao lưu toàn bộ cơ sở dữ liệu trong kho lưu trữ sẽ là một điều khôn ngoan để làm, mặc dù bạn có thể. Giữ riêng biệt.

Nếu bạn mới biết đến toàn bộ ý tưởng về hệ thống kiểm soát phiên bản, có lẽ bạn nên bắt đầu bằng cả hai chân. Tất cả sẽ bắt đầu có ý nghĩa khi bạn đi. Và tất nhiên, bởi bản chất của nó, bạn không thể làm bất cứ tổn thương vĩnh viễn nào kể từ khi bạn có thể cuộn qua lại.

Một đề xuất công ty: cam kết thường xuyên. Mỗi khi bạn thực hiện thay đổi có hiệu quả, hãy cam kết. Cam kết nhỏ hơn dễ xử lý hơn nhiều so với các cam kết lớn hơn. Ví dụ: nếu bạn cần hoàn tác thay đổi bị hỏng, bạn có nhiều khả năng có thể hoàn tác thay đổi này mà không xóa một đống mã đang hoạt động được cam kết cùng một lúc nếu cam kết của bạn là nguyên tử.

Answer 3

cho bán phá giá một regulary drupal db tôi sử dụng

a) một bí danh git cho việc tạo ra một sản phẩm nào, chi nhánh chưa được nối có tên là "db" tìm ra bí danh tại http://gist.github.com/360294

b) sự các lệnh sau, sử dụng các công cụ maatkit tuyệt vời, để trống một số bảng không thú vị và đổ db vào các tệp riêng biệt, mà không có ý kiến ​​

mk-find DBNAME --tbllike "cache%" --exec "TRUNCATE %D.%N"; 
mk-find DBNAME --tbllike "watchdog" --exec "TRUNCATE %D.%N"; 
git checkout db && \ 
cd /GITROOT/db && rm -rf * && \ 
mk-parallel-dump -d DBNAME -- mysqldump --skip-extended-insert --skip-comments --skip-lock-tables '%D' '%N' \> '%N.sql' 

Answer 4

1. Nói chung, môi trường của bạn gần gũi với nhau càng tốt. Điều này trở nên đặc biệt quan trọng khi cố gắng chẩn đoán và theo dõi các vấn đề. Nó không phải là nó không thể có các thiết lập khác nhau trong mỗi môi trường của bạn (dev, qa, prod, vv) nhưng tôi chắc chắn sẽ nói nó là thích hợp hơn để phù hợp nếu có thể.

2. Thiết lập kho lưu trữ git cho một chủ đề được chia sẻ là một ý tưởng tuyệt vời để xóa các vấn đề liên quan đến việc sao chép/dán các thay đổi của bạn. Cho dù bạn thiết lập một kho lưu trữ git trên máy chủ của riêng bạn hoặc sử dụng một dịch vụ như github thì hoàn toàn là vấn đề sở thích cá nhân.

3. Có, để hoàn toàn mọi thứ trong bản sao lưu, bạn cần thực hiện sqldump cơ sở dữ liệu ngoài việc có kho lưu trữ mã của bạn. Điều đó đang được nói, hãy sử dụng tự do mô-đun Features và nhận được càng nhiều cấu hình của bạn trong mã càng tốt. Điều này cũng giúp khi di chuyển giữa các môi trường cũng như có thể theo dõi các phiên bản thay đổi của bạn cùng với phần còn lại của mã. Một số hạng mục quan trọng nhất để thêm vào các tính năng của bạn sẽ được loại nội dung, quan điểm, quyền, các biến (thông qua Strongarm), khối vị trí (thông qua Context), menu, vv