2010-03-02 35 views
9

Phát triển web không giống như trước đây. Nó được sử dụng để bao gồm hack cùng một vài kịch bản PHP (tôi không có gì chống lại PHP, thực sự nó là ngôn ngữ lập trình chính của tôi), tải chúng qua FTP tới một số webhost và đó là điều đó. Ngày nay, mọi thứ phức tạp hơn. Như tôi có thể thấy bằng cách xem xét một số trang web chuyên nghiệp và hiện đại (SO là trang web chính, tôi coi SO là một ví dụ tuyệt vời về thực hành tốt trong phát triển web, ngay cả khi được tạo bằng ASP.NET và được lưu trữ trên Windows), một trang web là nhiều hơn thế:Cách tạo trang web phù hợp?

  1. các mã trang web thực sự là trong một kho lưu trữ (có ít svn sửa đổi ở chân làm cho cảm xúc của tôi Nerdy nức);
  2. Tệp tĩnh (CSS, JavaScript, hình ảnh) được lưu trữ trên một tên miền riêng biệt;

Ok, đây là những quan sát của tôi. Bây giờ cho câu hỏi của tôi:

  1. Bạn làm gì với tệp JavaScript và CSS? Bạn chỉ cần không giữ chúng dưới sự kiểm soát phiên bản? Điều đó có vẻ ngu ngốc. Bạn có tạo một kho lưu trữ riêng cho họ không?
  2. Làm cách nào để bạn thiết lập kho lưu trữ? Bạn chỉ cần tạo một trong thư mục gốc của máy chủ web? Hoặc bạn có tạo ra một loại trình kích hoạt sau cam kết sao chép các tệp mới nhất đến các đích thích hợp của chúng không?
  3. Điều gì sẽ xảy ra nếu bạn có nhiều máy chạy trang web và muốn đẩy một số thay đổi cho tất cả chúng?
  4. Mọi dự án như vậy đều phải có tệp cấu hình. Chúng khác với kho lưu trữ cục bộ đến kho lưu trữ từ xa. Ví dụ, trên máy phát triển của tôi, tôi không có mật khẩu gốc MySQL, trong khi trên máy chủ sản xuất, tôi chắc chắn có một mật khẩu. Mật khẩu này sẽ được lưu trữ trong một tập tin cấu hình, trong số những thứ khác, mà sẽ hoàn toàn khác trên máy tính của tôi và trên máy chủ. Có lẽ chúng cũng khác nhau giữa các máy sản xuất (như tôi đã nói trước đó, có thể trang web chạy trên nhiều máy để cân bằng tải). Làm cách nào để xử lý?

tôi đang tìm cách để bắt đầu một dự án web mới sử dụng:

  • Python + SQLAlchemy + Werkzeug + Jinja2
  • Apache httpd + modwsgi
  • MySQL
  • Mercurial

Điều tôi muốn là một số lời khuyên thực hành tốt nhất về cách sử dụng các công cụ và câu trả lời nói trên cho các câu hỏi của tôi ở trên.

+0

Tôi không biết phải chấp nhận câu trả lời nào. Tất cả chúng đều cung cấp cái nhìn sâu sắc rất hữu ích. Tuy nhiên, việc chọn một câu trả lời là "câu trả lời được chấp nhận" sẽ có vẻ không công bằng và, tốt, sai. Tất cả đều được chấp nhận. Đánh dấu bài đăng này là wiki cộng đồng có phải là một ý tưởng hay không? – Felix

Trả lời

5

Bạn nói đúng, mọi thứ có thể trở nên phức tạp khi cố gắng triển khai một trang web có thể mở rộng. Dưới đây là những gì tôi đã tìm thấy là một vài hướng dẫn tốt (từ chối trách nhiệm: Tôi là một kỹ sư đường ray):

  1. Hầu hết các quyết định liên quan đến cấu trúc tập tin cho kho lưu trữ mã của bạn được chủ yếu dựa trên các quy ước của ngôn ngữ, khuôn khổ và nền tảng bạn chọn để triển khai. Nhiều câu hỏi bạn đưa ra (JS, CSS, tài sản, sản xuất và phát triển) được xử lý bằng Rails. Tuy nhiên, điều đó có thể khác với PHP sang Python với bất kỳ ngôn ngữ nào khác mà bạn muốn sử dụng. Tôi đã tìm thấy bạn nên làm một số nghiên cứu về ngôn ngữ bạn đang sử dụng, và cố gắng tìm cách phù hợp với quy ước của cộng đồng đó. Điều này sẽ giúp bạn khi bạn đang tìm kiếm sự giúp đỡ về một trở ngại sau này. Mã của bạn sẽ được sắp xếp như mã của họ và bạn sẽ có thể nhận được câu trả lời dễ dàng hơn.

  2. Tôi muốn phiên bản kiểm soát mọi thứ không có kích thước đáng kể. Vấn đề duy nhất tôi đã tìm thấy với VC là khi repo của bạn trở nên lớn. Ngoài ra tôi chưa bao giờ hối hận khi giữ một phiên bản mã trước đó.

  3. Để triển khai cho nhiều máy chủ, có nhiều tập lệnh có thể giúp bạn thực hiện những gì bạn cần làm. Đối với Ruby/Rails, công cụ được sử dụng rộng rãi nhất là Capistrano. Có những tài nguyên có thể so sánh được với các ngôn ngữ khác. Về cơ bản bạn chỉ cần cấu hình những gì thiết lập máy chủ của bạn, và sau đó viết hoặc tìm đến mã nguồn mở cho một tập lệnh có thể triển khai/rollback/thao tác codebase của bạn đến các máy chủ mà bạn đã phác thảo trong tệp cấu hình của mình.

  4. Phát triển và sản xuất là một sự khác biệt quan trọng cần thực hiện. Trong khi bạn có thể hoạt động mà không có sự khác biệt đó, nó trở nên cồng kềnh một cách nhanh chóng khi bạn đang có để vá mã trên tất cả các kho lưu trữ của bạn. Nếu tôi là bạn, tôi sẽ viết một số mã được chạy vào đầu mỗi yêu cầu xác định môi trường bạn đang chạy. Sau đó, bạn có kiến ​​thức đó có sẵn cho bạn khi bạn xử lý yêu cầu đó.Thông tin này có thể được sử dụng khi bạn chỉ định cấu hình nào bạn muốn sử dụng khi bạn kết nối với db của mình, tất cả cách hiển thị thông tin gỡ lỗi trong trình duyệt chỉ khi phát triển. Nó có ích.

  5. Việc RESTful thường quyết định nhiều thiết kế của bạn liên quan đến cách các trang trên trang web của bạn được khám phá. Cố gắng giữ mã của bạn trong khung làm việc yên tĩnh giúp bạn nhớ vị trí mã của bạn, giữ cho định tuyến của bạn có thể dự đoán được, giữ cho mã của bạn không bị kết hợp quá nhiều và tuân theo quy ước ngày càng được chấp nhận. Rõ ràng là có các công ước khác có thể hoàn thành các mục tiêu tương tự, nhưng tôi đã có một trải nghiệm tuyệt vời khi sử dụng REST và nó đã cải thiện đáng kể mã của tôi.

Tất cả những gì được nói. Tôi đã tìm thấy rằng trong khi bạn có thể có ý định tốt để tạo ra một codebase nguyên sơ có thể mở rộng vô hạn và tốt đẹp và sạch sẽ, nó hiếm khi quay ra theo cách này. Nếu tôi là bạn, tôi sẽ làm một số lượng nhỏ nghiên cứu về những gì bạn cảm thấy thoải mái nhất và điều gì sẽ giúp làm cho cuộc sống của bạn dễ dàng hơn, và đi với điều đó.

Hy vọng điều đó sẽ hữu ích!

+1

Cảm ơn câu trả lời tuyệt vời. Tuy nhiên, bạn có ý nghĩa gì khi là RESTful? Mặc dù REST đã nhắc đến cách bạn thiết kế các API, chứ không phải cách bạn viết mã. Ngoài ra, REST yêu cầu statelessness và tôi thực sự không thể tưởng tượng một trang web không sử dụng phiên. – Felix

+0

Khi được sử dụng nghiêm ngặt với một API, vâng, bạn sẽ không giữ trạng thái. Tuy nhiên, không có gì sai khi sử dụng cùng phương pháp đó trong việc thiết kế cách lớp ứng dụng của bạn định tuyến các URL. Hệ tư tưởng này được cố thủ nặng nề trong cách thức đường ray tiến tới định tuyến. Xem xét mỗi bảng db dưới dạng tài nguyên, sử dụng ORM để truy cập các tài nguyên đó và làm cho phần Mô hình của bố cục MVC của bạn, bạn kết thúc với các url có thể dự đoán được, mã được tổ chức tốt, phù hợp với quy ước, rất DRY và khi bạn đến một ngày mà bạn đang incoporating một API. Đó là một quá trình chuyển đổi dễ dàng hơn nhiều. – Matthew

3

Mặc dù tôi có ít kinh nghiệm làm việc với các công cụ bạn đã đề cập, ngoại trừ MySQL, tôi có thể cung cấp cho bạn một số câu trả lời khá chuẩn cho các câu hỏi bạn đã đăng.

1) Tùy thuộc vào chi tiết, nhưng thông thường bạn giữ chúng trong cùng một kho lưu trữ nhưng trong một thư mục riêng biệt.

2) Chỉ vì một cái gì đó được cam kết với kho lưu trữ không có nghĩa là nó đã sẵn sàng để phát trực tiếp - nó thường là một công cụ trung gian có thể bị lỗi. Một xuất bản được thực hiện thủ công, với một xuất khẩu từ kho lưu trữ. Thiết lập máy chủ web trong cùng một thư mục như một thanh toán svn là một nono lớn như thư mục .svn chứa khá nhiều thông tin nhạy cảm, chẳng hạn như làm thế nào để đẩy các thay đổi vào máy chủ svn.

3) Bạn sử dụng một số loại giải pháp NAS hoặc SAN hoặc đơn giản là chia sẻ mạng trên một trong các máy chủ và đọc tất cả dữ liệu của bạn từ đó. Bằng cách đó, khi bạn đẩy thông tin đến một nơi, tất cả các máy chủ đều có thể truy cập thông tin đó. Nếu mạng của bạn chậm, bạn thiết lập các tập lệnh tự động đẩy các tệp ra tất cả các máy chủ từ một vị trí duy nhất. Nếu bạn sử dụng môi trường đa máy chủ trong ASP.NET, đừng quên cập nhật khóa máy trong các tệp cấu hình hoặc bộ nhớ cache được mã hóa được chia sẻ của bạn, chẳng hạn như ViewState, sẽ không hoạt động trên các máy chủ. Có một cửa hàng phiên trong cơ sở dữ liệu cũng là một ý tưởng tốt.

4) Tôi đã có bước tạo bài đăng chỉ kích hoạt trên xuất bản thay thế kết nối cơ sở dữ liệu của tôi bằng sản xuất và cũng thay đổi giá trị cấu hình ứng dụng Sản xuất của tôi từ false thành true trong web.config/app.config đã xuất bản các tập tin. Tôi không thể thấy bất kỳ trường hợp nào bạn muốn các tệp cấu hình khác nhau cho các máy chủ khác nhau phân phát cùng một nội dung.

Nếu có điều gì đó không rõ ràng, chỉ cần nhận xét và tôi sẽ cố làm rõ.

Chúc may mắn! // Eric Johansson

+0

Cảm ơn câu trả lời tuyệt vời. Dưới đây là một số ghi chú. Ngày 1: có, nhưng nếu các tệp tĩnh nằm trên một tên miền khác (có thể có nghĩa là máy chủ khác nhau), một kho lưu trữ riêng biệt có vẻ là bắt buộc? Ngày 2: với Mercurial, cam kết và đẩy là những thứ riêng biệt. Bạn cam kết (bao nhiêu lần bạn muốn) vào kho lưu trữ cục bộ của bạn và sau đó đẩy đến kho trung tâm. Vì vậy, tôi không thể thấy lý do nào để đẩy nếu mã không sẵn sàng để sản xuất. Thêm vào đó, Mercurial chỉ tạo ra một thư mục .hg trong thư mục cấp cao nhất của dự án, vì vậy việc phá vỡ vấn đề thông tin nhạy cảm sẽ dễ dàng.3 & 4 - không có bình luận, cảm ơn! – Felix

1

Tôi nghĩ bạn đang trộn 2 khía cạnh khác nhau, kiểm soát và triển khai nguồn. Chỉ vì bạn có tất cả các tệp của bạn trong một kho lưu trữ duy nhất không có nghĩa là chúng phải được triển khai theo cách đó. Nó cũng có thể tranh cãi cho dù bạn nên triển khai trực tiếp bằng cách sử dụng điều khiển nguồn hoặc thay vì sử dụng một kịch bản xây dựng/triển khai có thể xử lý bất kỳ số lượng cấu hình nào.

Cũng lưu trữ các tệp tĩnh trên một miền riêng biệt chỉ thực sự trở nên đáng giá trên các trang web lưu lượng truy cập cao. Bạn có chắc là bạn không tối ưu hóa sớm không?

+0

Khi tạo các ứng dụng web bằng Python, không có "tài liệu gốc" trong cấu hình máy chủ web của bạn. Tất cả các yêu cầu được xử lý bởi một tệp ứng dụng (về cơ bản là một tập lệnh Python). Điều này làm cho việc lưu trữ các tệp tĩnh trên một tên miền riêng biệt thậm chí hữu ích hơn, ngay cả khi, lúc đầu, miền riêng biệt đó được lưu trữ trên cùng một máy với tên miền chính. – Felix

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