Xin chào các bạn, ai cũng biết rằng phát triển phần mềm ở nhiều công ty khác nhau thường được chia thành các loại môi trường phát triển khác nhau, chẳng hạn như: phát triển, dàn dựng và sản xuất. Trong bài viết này, tôi sẽ giới thiệu các khái niệm về 3 môi trường phổ biến nhất như vậy (tất nhiên, không áp dụng cho tất cả các công ty, thậm chí tùy thuộc vào dự án) và tôi sẽ thảo luận về Mẹo để triển khai sản xuất hiệu quả p>
Môi trường phát triển
- Đây là môi trường đầu tiên và nó sẽ có trên máy tính của bạn (còn được gọi là môi trường cục bộ).
- Đây sẽ là nơi bạn viết các tính năng hoặc khắc phục sự cố. Có một lỗi.
- Cấu hình thường khác với dàn dựng và sản xuất.
- Môi trường này sẽ kết nối với cơ sở dữ liệu cục bộ hoặc mã giả cơ sở dữ liệu, vì vậy bạn có thể viết mã mà không ảnh hưởng đến dữ liệu thực tế.
- Môi trường này có thể cài đặt các gói giúp gỡ lỗi dễ dàng hơn.
Môi trường sân khấu
- Môi trường công đoạn sẽ giống như môi trường sản xuất.
- Môi trường này sẽ không còn được cài đặt trên máy cục bộ nữa mà được đẩy lên máy chủ.
- Môi trường này sẽ là nơi lý tưởng để những người kiểm thử của dự án, những nhân viên đảm bảo chất lượng kiểm tra hệ thống trước khi đi vào sản xuất.
- Nếu dự án đến từ khách hàng, chúng tôi có thể có được môi trường làm bản demo cho khách hàng và họ sẽ hiểu cách hoạt động của các tính năng trước khi tiếp cận người dùng.
Sản xuất
- Môi trường này là nơi quan trọng nhất, nơi tất cả các cập nhật và kiểm tra được thực hiện bởi người dùng cuối.
- Đây là nơi các công ty kiếm tiền. Vì vậy, đó là lý do tại sao các nhà phát triển không thể có bất kỳ lỗi nghiêm trọng nào ở đây.
- Mọi lỗi hoặc lỗi còn sót lại sẽ được người dùng và nhóm dự án phát hiện, tôi hy vọng đó là một lỗi nhỏ.
Trình quản lý gói
- Trong mỗi dự án, chúng tôi thường sử dụng các công cụ để giúp quản lý các gói và thư viện một cách hiệu quả, chẳng hạn như: composer, npm, fiber, v.v. Sử dụng hiệu quả trong môi trường sản xuất
Đối với những người sử dụng php thuần túy hoặc một số framework, laravel hoặc codeigniter có lẽ không còn xa lạ với các lệnh cấp thần
Được chứ? Nó làm gì? Nó cài đặt các thư viện được khai báo trong tệp composer.json hoặc composer.lock vào thư mục dự án. Và khi triển khai vào production thì tất nhiên nó cũng sẽ chạy lệnh đó. Tôi đã đọc rất nhiều loạt bài về triển khai và cũng đã đề cập đến việc chạy lệnh cài đặt composer để cài đặt nhà cung cấp.
Tuy nhiên, với tôi, nếu chúng ta chỉ chạy lệnh trên trong sản xuất, chúng ta cần xem xét lại. Hãy quay lại môi trường phát triển ở trên, nơi tôi đã đề cập rằng gói hỗ trợ gỡ lỗi đã được cài đặt.
Ví dụ laravel debugbar điển hình trong tài liệu laravel-debugbar, bên dưới hướng dẫn cài đặt
Bạn có thấy điều gì lạ không? Đúng vậy, nó có một tùy chọn -dev (là một cờ mà gói sẽ được cài đặt trên một môi trường phát triển cụ thể trong composer.json, nó sẽ nằm trong request-dev ) Có nhiều người cài đặt thư viện trong composer hoặc npm và họ sẽ có thể bỏ qua các tùy chọn như thế này.
-no-dev
Như tôi đã đề cập ở trên, nhiều người sẽ chạy cài đặt composer, có nghĩa là họ sẽ cài đặt ngay cả các gói được khuyến nghị chỉ cài đặt trong môi trường. Những bất lợi của các trường đang phát triển là:
- Các gói được khuyến nghị cài đặt trong môi trường nhà phát triển có thể có nhiều lỗ hổng. Nếu được triển khai trong phiên bản sản xuất, chúng tôi sẽ không thể đối phó với rủi ro do các gói đó gây ra.
- Chiếm không gian máy chủ, không gian máy chủ rất lớn Điều quan trọng, trong môi trường phát triển chúng tôi sử dụng không gian trên máy cục bộ, nó có thể là 200gb 500gb 1tb nó không quan trọng. Nhưng môi trường sản xuất 10gb và 20gb cũng có một mức giá nhất định cho quý khách hàng. Dưới đây tôi sẽ nói chi tiết về phần này thông qua trường hợp trải nghiệm của bản thân.
Bạn cũng cần chú ý khi sử dụng cờ này. Gần đây tôi đã gặp một trường hợp thực tế trong dự án của mình. Đó là dự án mà tôi đã cài đặt gói laravel debugbar là một nhà cung cấp được đăng ký trong config / app. Nó không thực sự quan trọng về cơ bản nó được cài đặt trên nó khi chạy trong một môi trường phát triển. Tuy nhiên, dự án của tôi sử dụng công cụ triển khai như một trình triển khai, về cơ bản một công cụ như thế này tự động chạy trình soạn nhạc với cờ no-dev . Vì vậy, khi triển khai, nó sẽ vô tình bỏ qua laravel debugbar có nghĩa là mã đăng ký nhà cung cấp trong config / app sẽ chết =>; app chết.
-no-ansi
- Cờ này sẽ vô hiệu hóa đầu ra ansi, có nghĩa là khi chúng tôi chạy cài đặt composer, nó sẽ loại bỏ màu đỏ hoặc hiện tượng sử dụng biểu đồ
- làm cho màu sắc của chúng tôi trông đẹp, nhưng nếu chúng tôi chạy cài đặt composer theo cách thủ công thì ngày nay chúng tôi có thể không muốn có các ký tự ansi trong các tệp nhật ký của tôi khi triển khai sản xuất bằng các công cụ triển khai / cd tự động.
Hệ điều hành: ubuntu hoặc centos
Có nhiều tùy chọn để chọn hệ điều hành nào làm máy chủ cho dự án của tôi, với tư cách là nhà phát triển php, những tùy chọn phổ biến nhất mà tôi thấy là máy chủ centos và > máy chủ ubuntu . Dù bạn đang triển khai chuyên nghiệp hay người mới làm quen thì mình khuyên bạn nên chọn 1 trong 2 phiên bản này là đáng tin cậy nhất. 3 điểm khác biệt lớn nhất giữa hai anh chàng này
- ubuntu dựa trên debian, centos dựa trên linux doanh nghiệp mũ đỏ
- gói cài đặt ubuntu sử dụng trình quản lý gói apt-get , trong centos chúng ta phải sử dụng yum được sử dụng để tải xuống và cài đặt các gói rpm.
- centos là phiên bản ubuntu ổn định vì mật độ cập nhật phần mềm thấp hơn.
Điểm tôi muốn nhắc đến là điểm thứ 3, tính ổn định của centos là các phiên bản của nó rất ít khi được cập nhật, thường chỉ những phiên bản quan trọng mới được cập nhật. Và đây cũng là điểm yếu của centos, vì nếu đôi khi muốn cập nhật HĐH có thể phải cập nhật thủ công, nhưng cá nhân mình nghĩ môi trường sản xuất luôn cần sự ổn định.
Tôi đã gặp trường hợp vào một ngày đẹp trời, tôi triển khai mã tới một máy chủ và nhận được thông báo rằng nó đã quá tải (Tôi đang chạy cài đặt tổng hợp máy chủ đó đang sử dụng Hệ điều hành ubuntu (sau này bạn sẽ nhận ra code là mấy dòng code mà chả hiểu sao khoảng trắng cứ bị mất dấu =)))) Mình mất cả ngày trời để tìm nguyên nhân và khắc phục. Kết quả tôi nhận được là máy chủ có quá nhiều bản cập nhật cho ubuntu.
Sau mỗi lần cập nhật, tôi phải thu thập thông tin vào một thư mục có vẻ như chứa các tệp như kernel – * – * .
Và việc chúng ta cần làm là: dọn dẹp, xóa các tệp đó đi. Tất nhiên trước khi xóa chúng ta phải kiểm tra xem hệ điều hành của mình sử dụng tệp nào và sử dụng phiên bản nào. Sau khi xóa thì vấn đề dung lượng sẽ được giải quyết.
Ở bài viết này chủ yếu mình muốn chia sẻ với các bạn các trường hợp mình đã gặp phải, cũng như nêu ra quan điểm của mình về môi trường Production. từ việc quản lý gói cho tới hệ điều hành sử dụng, dung lượng trên production v…..v Còn quan điểm của các bạn thì sao hay có các case thực tiễn nào khác bạn đang gặp phải vui lòng để lại ý kiến để chúng ta hoàn thiện bài viết hơn nữa nhé 