Nhà phát triển web - Có tốt hơn để phát triển trên máy cục bộ của bạn hoặc trên máy chủ từ xa không?

Question

Ưu điểm/khuyết điểm của việc phát triển web trên máy cục bộ của bạn thay vì trên một máy chủ phát triển tập trung là gì? Đối với những người làm dev trên máy cục bộ của bạn, làm thế nào để bạn giữ một kiến ​​trúc db được cập nhật để phát triển cục bộ khi có nhiều nhà phát triển tham gia? Cụ thể, tôi hiện đang thử nghiệm với XAMPP cho PHP và tò mò làm cách nào để giữ cá thể MySQL DB trên máy cục bộ của tôi đồng bộ khi các nhà phát triển khác thường xuyên thay đổi cấu trúc dữ liệu/db.

Phát triển địa phương chỉ có thực tế khi làm việc một mình không?

Answer 1

• Luôn, luôn phát triển trên thiết lập cục bộ.
• Luôn sử dụng điều khiển nguồn.
• Luôn đặt mọi thứ dưới sự kiểm soát nguồn, bao gồm lược đồ cơ sở dữ liệu.

Dường như có rất nhiều người muốn có một máy chủ trung tâm mà mọi người sử dụng để phát triển - tôi thực sự không hiểu tại sao bạn muốn ở trong môi trường chung nơi mọi người thực hiện thay đổi có thể làm gián đoạn quá trình phát triển.

Trong cửa hàng tất cả mọi người tôi có máy chủ web phát triển của riêng mình và cơ sở dữ liệu phát triển riêng của họ (thường colocated trên cùng một cơ sở dữ liệu máy chủ , nhưng cơ sở dữ liệu riêng của họ). Bằng cách đó, chúng được cách ly hoàn toàn với các nhà phát triển khác và không thể làm gián đoạn lẫn nhau.

Khi triển khai đối tượng địa lý hoặc sửa lỗi, họ kiểm tra mã của họ và lược đồ cơ sở dữ liệu phù hợp để nó có sẵn cho các nhà phát triển khác dưới dạng đơn vị hoàn chỉnh. Phát hành cho máy chủ thử nghiệm hoặc máy chủ triển khai được thực hiện từ một phiên bản có nhãn trong kho lưu trữ mã nguồn.

Ổn định và lành mạnh! Tôi không hiểu tại sao bạn lại làm theo cách khác khi các máy chủ phát triển hoàn toàn miễn phí!

Answer 2

Thông thường bạn sẽ có một máy chủ phát triển địa phương mà mọi người chia sẻ.

Answer 3

Đối với một tình huống như thế, tôi luôn thực hiện nó trên máy chủ phát triển. Vì không có biên dịch lại. Bạn luôn có thể có được một ảnh chụp nhanh DB mới mỗi ngày và mang nó xuống máy của bạn. Hoặc chỉ cần có máy chủ web địa phương và điểm DB vào hộp dev.

Answer 4

Tôi đã tìm thấy rằng chạy một máy chủ web cục bộ, với DB từ xa hoạt động tốt nhất. DB sao chép/đồng bộ hóa là một nỗi đau, vì vậy tôi chỉ làm việc với một DB địa phương nếu tôi thực sự đã phải.

Làm việc với máy chủ web cục bộ mặc dù loại bỏ tất cả sự phiền toái và chậm chạp khi tải lên các trang/mã giữa các thay đổi.

Answer 5

Ưu điểm đến địa phương:

• hoạt động ngay cả mạng đi xuống
• bạn biết tất cả các công cụ trên máy tính này

Nhược điểm đến địa phương:

• phải đồng bộ hóa mọi thứ đến máy chủ triển khai
• không có ver kiểm soát sion bạn có thể clobber của người khác làm việc

Ưu điểm đến trung tâm:

• mọi người đều có công cụ giống hệt
• luôn làm việc về nội dung "thực"

Nhược điểm đến trung tâm:

• không thể hoạt động nếu mạng bị ngắt
• (các) công cụ "yêu thích" của bạn có thể bị thiếu

Tôi chắc chắn có nhiều hơn, nhưng những điều này trở nên nghiêm túc.

Answer 6

Tôi nghĩ tốt nhất nên thiết lập cục bộ hoàn toàn dưới sự kiểm soát của bạn trong quá trình phát triển để đảm bảo rằng các thay đổi được thực hiện bởi các nhà phát triển khác không can thiệp vào chính bạn. Tôi có thiết lập môi trường phát triển và thử nghiệm cục bộ để tôi có thể thực hiện cả hai tác vụ mà không cần phải tính đến các nhà phát triển khác.Tôi liên tục chạy các bài kiểm tra của mình khi tôi viết mã bằng cách sử dụng autotest, có nghĩa là tôi có thể chắc chắn rằng mã của tôi là chính xác và đáp ứng đặc điểm kỹ thuật chính xác.

Sau khi cơ sở mã theo thứ tự, tôi triển khai đến một máy chủ dàn dựng (một môi trường gần như sản xuất nhất có thể) và chạy lại các thử nghiệm. Chúng tôi cũng sử dụng giai đoạn của mình để chạy thử nghiệm tải và thực hiện kiểm tra người dùng.

Answer 7

Phát triển và 'thử nghiệm' trên máy cục bộ là Ok nhưng kiểm tra chất lượng phải được thực hiện trên hệ thống phản ánh môi trường đích, nghĩa là không có tất cả các công cụ phát triển, vv được cài đặt.

Điều này sẽ giúp tránh tình huống 'hoạt động tốt trên máy của tôi'.

Answer 8

Cả hai. Thực hiện một số thử nghiệm tích hợp và đơn vị trên máy chủ phát triển của bạn (lý tưởng, nên tương tự như máy chủ trực tiếp của bạn nhất có thể, nhưng ở địa phương), sau đó thực hiện một số thử nghiệm chấp nhận trong môi trường QA. máy chủ hoặc chính xác thiết lập tương tự (phần cứng, phần mềm, v.v.) và phải ở xa.

Khi nói đến phần cơ sở dữ liệu của các câu hỏi, bạn có thể một trong hai:

• mỗi người đều có bản sao của riêng bạn của cơ sở dữ liệu HOẶC
• giữ cho dữ liệu/cấu trúc đồng bộ bằng cách chạy một kịch bản tập trung (có thể là một phần của bản dựng của bạn)

Answer 9

Một vấn đề với thử nghiệm trên máy chủ cục bộ là bạn có thể bỏ lỡ những thứ liên kết đến tệp cục bộ thay vì truy cập được qua trình duyệt. Cha tôi luôn đặt các liên kết trên trang web của câu lạc bộ camera của anh ấy, đó là những thứ như 'a href =' C: \ My Documents \ Camera Club \ Photos ... ", và khi tôi nói với anh ấy rằng anh ấy đã đánh dấu nó , anh ta nói "nó làm việc cho tôi". Tương tự như vậy trong một môi trường chuyên nghiệp, bạn có thể có những thứ mà bạn quên kiểm tra trong điều khiển mã nguồn, và do đó chúng sẽ không được triển khai trên máy chủ thực.

Một giải pháp thỏa hiệp có thể là có VM, VirtualBox hoặc VMWare hoặc Parallels, để bạn có thể kích hoạt hộp ảo Solaris, Windows, Mac và/hoặc Linux để kiểm tra. trong các trình duyệt mặc định trên mỗi trình duyệt, cộng với bạn có thể đảm bảo mọi thứ thực sự hoạt động thông qua kết nối không phải cục bộ. Thậm chí tốt hơn có thể là có một máy ảo mà bạn triển khai và sử dụng máy chủ web đó để thử nghiệm.

Nếu hệ điều hành cơ sở của bạn là OpenSolaris, bạn thậm chí có thể sử dụng ZFS và sử dụng ảnh chụp nhanh để khôi phục máy ảo về trạng thái cơ bản sau mỗi lần chạy thử.

Answer 10

FWIW, tôi sẽ đề cập rằng thiết lập của chúng tôi giống như những gì ông Matt mô tả. Mỗi dev được sandbox cá nhân của riêng mình để gây rối, với máy chủ web của riêng mình và DB. Trên bờ vực phát hành, mã được kiểm soát phiên bản là ảnh chụp nhanh/phân nhánh và được di chuyển đến một máy chủ dàn dựng được cho là bắt chước môi trường sống thật gần nhất có thể. Thử nghiệm sau đó, sau đó phát hành được thực hiện cho một môi trường sản xuất.

Đối với các dự án riêng của tôi (không liên quan đến công việc), tôi phát triển tại địa phương, sau đó đẩy trực tiếp. Một hoặc hai dự án có thể có một máy chủ thử nghiệm trung gian/môi trường giữa phát triển và công cộng/sống.

Answer 11

Tôi đã xây dựng một trang web trong Ruby on Rails và tôi đã phát triển cục bộ nhưng triển khai đến một máy từ xa thường xuyên nhất có thể. Tôi đọc trong Agile Web Development with Rails rằng càng có nhiều bạn thực hành triển khai tốt hơn bởi vì khi đến lúc triển khai để sản xuất - sẽ không có bất ngờ.

Answer 12

Theo cách giữ cho DB của bạn "đồng bộ hóa" khi những người khác đang chỉnh sửa nó. Một cách xung quanh điều này là để có được lược đồ DB của bạn dưới sự kiểm soát phiên bản. Điều này không đơn giản như việc đặt mã nguồn của bạn dưới sự kiểm soát phiên bản, và có nhiều cách khác nhau để xử lý nó.

đã đọc bài này trên Coding Horror:

http://www.codinghorror.com/blog/archives/001050.html

Không quá nhiều bài riêng của mình nhưng sáu điều ông liên kết đến bởi K. Scott Allen. Về cơ bản những gì được mô tả trong các bài viết này là một phương pháp baselining lược đồ cơ sở dữ liệu, kiểm tra trong một tập tin .sql của đường cơ sở đó, và từ đó bạn viết các tập lệnh thay đổi .sql "mỗi khi bạn thay đổi lược đồ. Bây giờ mỗi khi một nhà phát triển kiểm tra hoặc cập nhật một bản sao làm việc, bất kỳ kịch bản thay đổi xuất sắc nào sẽ được chạy. Bạn sẽ cần thiết lập một số tập lệnh/công cụ để tự làm điều đó trừ khi bạn sử dụng một khung làm việc này cho bạn.

Answer 13

Một lý do khác để làm việc cục bộ là mọi thứ chạy nhanh hơn. Điều này chuyển thành phát triển nhanh hơn. Mạng chậm trễ có thể là kẻ giết người năng suất!

Answer 14

Ở vị trí hiện tại của tôi, tôi phát triển trên máy tính của riêng mình. Đối với các dự án nhỏ hơn, tôi chỉ sử dụng máy chủ web nhẹ có giao diện với Visual Studio. Tôi cũng có SQL Server 2005 và 2008 được thiết lập trên máy tính của riêng tôi cho mục đích phát triển và thử nghiệm ban đầu.

Điều này đã làm việc tốt cho tôi; một trong những vấn đề tôi đã chạy vào là (như những người khác đã lưu ý) giữ cơ sở dữ liệu đồng bộ là một loại đau. Gần đây tôi đã chuyển sang migrator dot net - về cơ bản là .NET thực hiện việc di chuyển Ruby on Rails - để giữ cơ sở dữ liệu cục bộ/dàn dựng/sản xuất/đồng bộ hóa và điều đó khiến cuộc sống của tôi ít căng thẳng hơn. Một công cụ như thế này cũng làm cho nó dễ dàng hơn để làm việc trên cơ sở dữ liệu trong môi trường nhóm, mặc dù bạn phải có kỷ luật đủ để sử dụng nó một cách nhất quán.Kinh nghiệm của tôi ở đây đã thuyết phục tôi rằng phát triển địa phương kết hợp với một số loại quy trình kiểm soát thay đổi db, máy chủ tích hợp liên tục và hệ thống kiểm soát phiên bản tốt hỗ trợ hợp nhất (chúng tôi sử dụng TFS) là cách tốt nhất để đi. Điều đó cho phép mọi người làm việc riêng của họ mà không cần bước vào người khác, nhưng cũng đảm bảo rằng các thay đổi sẽ được hợp nhất đúng cách. Trong công việc trước đây của chúng tôi, chúng tôi sử dụng IIS trên máy tính của chúng tôi kết hợp với một cơ sở dữ liệu phát triển chuyên dụng và đây là một chút PITA - bạn phải cẩn thận để không chạy bất kỳ quá trình nào có thể làm hỏng cơ sở dữ liệu hoặc thậm chí là lộn xộn dữ liệu vì nó có thể ảnh hưởng đến các nhà phát triển khác và IMO, loại đó đã đánh bại mục đích của việc có một DB phát triển ngay từ đầu.

Answer 15

Tôi là cửa hàng một người; Tôi có cả máy chủ từ xa và máy chủ cục bộ.

Tôi sử dụng máy chủ cục bộ để tạo mẫu nhanh và chu kỳ phát triển ban đầu, nơi tôi thực hiện nhiều thay đổi và cần kiểm tra nhanh chóng. Khi nó đến một giai đoạn gần như alpha, tôi sẽ thiết lập một máy chủ phụ tùy chỉnh cho dự án và triển khai đến máy chủ của tôi. Có một số tính năng nhất định không thể thử nghiệm cục bộ - tức là. đăng ký người dùng dựa trên e-mail - và vì vậy các tính năng này được phát triển trên máy chủ từ xa. Vì nó là MINE, và không phải là triển khai thực sự, nó vẫn hầu như không có lag. Vì tôi có một VPS, tôi có toàn quyền kiểm soát môi trường phát triển trên cả hai máy.

Answer 16

Tôi nhận thấy rằng việc phát triển mã trên các máy cục bộ bằng cách sử dụng điều khiển nguồn trong khi truy cập vào một DB phát triển tập trung đã làm việc rất tốt. Việc giữ nhiều DB trong đồng bộ được chứng minh là khó.