Cách tự động hoá và tối ưu phát triển và kiểm tra WordPress với Pantheon

Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

() translation by (you can also view the original English article)

Trong bài hướng dẫn trước đó, tôi hướng dẫn bạn các bước để bắt đầu tạo ra và bảo trì một trang WordPress an toàn bằng thiết lập 3 môi trường "Dev-Test-Live" trên Pantheon. Với cấu hình như vậy, bạn luôn cập nhật code trong mội trường Dev, sau đó kiểm tra trên môi trường Test, và chỉ một khi mọi thứ trông ổn thoã, rồi đưa nó lên server Live.

Khi đây là một sự cải thiện đáng kể so với việc tạo ra một bản cài đặt WordPress trong môi trường đơn lẻ và upload thay đổi thẳng lên server Live, chúng ta có thể làm điều tốt hơn!

"Việc yêu cầu các chuyên gia làm những nhiệm vụ tẻ nhạt, lặp lại và về kỹ thuật là phương pháp dĩ nhiên nhất để bảo đảm các lỗi do người mà chúng ta có thể nghĩ tới, thiếu ngủ hoặc say xỉn."

Trích dẫn từ David Farley tóm tắt vấn đề với thiết lập hiện tại: trong khi có 3 môi trường và một quá trình sử dụng chúng, chúng ta vẫn đang làm việc thủ công, dễ dàng gây ra các sai sót.

Trong hướng dẫn này, để giải quyết vấn đề này nhiều nhất có thể, đầu tiên tôi sẽ cho bạn thấy làm sao để thực hiện các nhiêm vụ lặp lại nhanh hơn bằng các công cụ dòng lệnh Pantheon, và sau đó chúng ta sẽ xem phần tự động hoá. Chính xác hơn, chúng ta sẽ nhìn vào việc tự động hoá các kiểm tra acceptance của bạn bằng server tích hợp liên tục và framework kiểm tra Behat.

Sau khi hoàn tất hướng dẫn, bạn sẽ có hiểu biết vững chắc về quy tắc phát triển và cài đặt một trang WordPress đáng tin và dễ bảo trì trên Pantheon. Bạn cũng sẽ đươc trang bị nhiều ý tưởng trong việc làm sao để cấu hình tốt hơn, một cải tiến nhỏ từng lúc.

Hãy bắt đầu nào!

1. Sử dụng công cụ dòng lệnh Terminus để kiểm soát trang Pantheon của bạn

Trong khi trang điều khiển web của Pantheon cho bạn cái nhìn rõ ràng về điều đang diễn ra trên 3 server và những công cụ tuyệt vời để quản lý chúng, thay vào đó có những lúc bạn sẽ thích một công cụ dòng lệnh hơn.

Nó có thể tiết kiệm thời gian: khi bạn làm việc với site, bạn sẽ nhanh chóng chú ý rằng thời gian bỏ ra trong một nhiệm vụ đơn giản nhưng tẻ nhạt - chẳng hạn đưa các thay đổi hoặc triển khai lên môi trường Test - trở thành một phần quan trọng của việc bạn làm mỗi ngày. Hoặc có thể chỉ vì bạn muốn làm việc với dòng lệnh. Hoặc có lẽ bạn muốn tạo một script tổng hợp nhiều hành động như là đưa code của bạn lên, triển khai nó lên Test, và xoá bộ nhớ đệm chỉ trong một lệnh.

Công cụ dòng lệnh Pantheon, Terminus, hãy để bạn thực hiện tất cả điều này - và nhiều nữa.

Bước 1: Cài đặt Terminus

Trước khi bạn có thể bắt đầu sử dụng Terminus, bạn sẽ cần cài đặt trên máy tính của bạn.

Hướng dẫn cài đặt và sử dụng hiện diện trong hướng dẫn này là một hệ thống trên nền Unix (như MacOS X hoặc Linux). Nếu bạn dùng Windows, những lệnh này có chút khác biệt - kiểm tra các hướng dẫn cài đặt Terminus cho nhiều thông tin hơn.

Terminus có những yêu cầu hệ thống sau đây, vậy bảo đảm bạn đã cài đặt trước khi tiếp tục:

PHP phiên bản 5.5.9 hoặc cao hơn
PHP-CLI
PHP-CURL

Dù Terminus không yêu cầu, tôi khuyên khích bạn cũng cài đặt Composer để hoàn thành hướng dẫn. Tôi cũng giả định rằng bạn đã dùng Git khi chúng ta đã nói về nó trong những bài hướng dẫn trước đây.

Có nhiều cách khác nhau để cài đặt Terminus (bạn có thể thấy các hướng dẫn cài đặt chi tiết), nhưng hãy chọn giải pháp đơn giản nhưng không yêu cầu các công cụ khác để vận hành.

Trong cửa sổ console, nhập vào:

1	$ curl https://github.com/pantheon-systems/terminus/releases/download/0.11.1/terminus.phar -L -o /usr/local/bin/terminus && chmod +x /usr/local/bin/terminus

Câu lệnh cài đặt Termins đển /usr/local/bin/terminus trên máy tính của bạn.

Một khi cài đặt hoàn tất, bạn có thể kiểm tra bằng câu lệnh sau đây:

1	$ terminus art

Một trong những logo ASCII khác biệt sẽ hiện ra. Đây là biểu tượng nắm tay tia sét của Terminus, ví dụ:

Bước 2: Đăng nhập vào Terminus

Trước khi bạn có thể sử dụng Terminus để quản lý tài khoản Pantheon và các trang liên kết tới nó, bạn sẽ cần đăng nhập.

Có 2 chọn lựa để thực hiện điều này: bạn có thể đăng nhập bằng email và password của Pantheon hoặc dùng machine token để xác định máy tính bạn đang đăng nhập vào.

Chúng ta sẽ theo phương pháp machine token vì nó mang lại mức độ bảo mật cao hơn. Nếu máy tính của bạn bị tổn hại và bạn cần vô hiệu đăng nhập vào nó, bạn có thể thu hồi machine token, và không ai có thể truy xuất tài khoản của bạn từ máy tính đó nữa. Machine token cũng hữu dụng nếu bạn chạy Terminus trên nhiều máy và các script tự động hoá - ví dụ trên server tích hợp liên tục (continuos integration).

Mỗi machine token bạn tạo ra cho máy của người dùng cùng quyền truy xuất vào tài khoản Pantheon giống bạn. Vậy bảo đảm thu hồi bất kỳ token nào để không ai có thể sử dụng nữa.

Để tạo machine token đầu tiên của bạn, đăng nhập vào tài khoản Pantheon. Sau đó, trong tab Account, chọn tuỳ chọn menu Machine Tokens.

Chọn Create Token. Sau đó, ở màn hình kế tiếp, nhập vào một tên gợi tả và click Generate Token.

Tiếp đến, bạn sẽ thấy một popup hiển thị token vừa được tạo ra cùng với một câu lệnh để lưu nó vào Terminus trên máy tính của bạn.

Copy Terminus command và chạy nó trong command line.

1	$ terminus auth login --machine-token=TOKEN

Khi câu lệnh hoàn tất, Terminus đã sẵn sàng sử dụng trên máy tính của bạn.

Hãy nhìn xem bạn có thể làm gì với nó!

Bước 3: Tổng quan của các lệnh Terminus

Trong phần còn lai của hướng dẫn, ta sẽ dùng các lệnh của Terminus khi ta thiết lập kiểm tra tự động cho trang WordPress của bạn. Tuy nhiên, đó chỉ là bước khởi đầu, vậy trước khi thực hiện, hãy xem qua vài câu lệnh và bạn có thể học thêm về chúng như thế nào.

Cách này, một khi bạn hoàn thành hướng dẫn, bạn sẽ những lời khuyên bạn có thể dùng để tìm ra cách tốt hơn để cải thiện quy trình làm việc của bạn theo ý thích của mình.

Bạn có thể tìm một danh sách cập nhập của các lệnh Terminus trong Terminus Wiki.

Danh sách này không có phần tài liệu cho các câu lệnh, vậy khi bạn thấy một câu lệnh mà bạn muốn dùng, hãy dùng công cụ Terminus để biết thêm về nó bằng cách gõ:

1	$ terminus help <command> <subcommand>

Nếu bạn bỏ qua <subcommand> , Terminus sẽ cho bạn xem danh sách các subcommand (lệnh phụ) dược hỗ trợ cho một câu lệnh cụ thể.

Giờ hãy xem một số câu lệnh hữu dụng bạn có thể dùng để thực hiện các hành động từ hướng dẫn trước trực tiếp trên dòng lệnh.

Quản trị các website

Để xem danh sách các website của bạn trên Pantheon, gõ:

1	$ terminus sites show

Cũng có rất nhiều câu lệnh để tạo ra một site mới (terminus sites create) và import một site (terminus sites import) mà không cần vào trang dashboard (trang quản trị) Chúng có thể hữu dụng nếu bạn là một công ty hoặc thường xuyên tạo site. Với số còn lại trong chúng ta, dashboard vẫn hiệu quả.

Một lệnh hữu dụng nữa nếu bạn vận hành nhiều trang là terminus sites mass-update, bạn có thể dùng nó để cập nhật tất cả trang dev với một bản cập nhật upstream đã hoàn thành (trong trường hợp của chúng ta, một phiên bản WordPress mới).

Push (cập nhật) và deploy (triển khai) thay đổi của bạn

Hầu hết công việc khi phát triển một website là viết, triển khai và kiểm tra code. Vậy dù bạn làm việc trong Git hoặc chế độ SFTP, bạn sẽ làm rất nhiều về nó. Đó là lý do nó cũng là một lĩnh vực bạn sẽ thu lợi nhiều nhất từ việc sử dụng giao diện dòng lệnh hơn là thực hiện mọi hoạt động thông qua Web Dashboard.

Những hoạt động này được nhóm lại qua lệnh site - bạn có thể thấy danh sách toàn bộ bằng cách gõ vào:

1	$ terminus help site

Khi đây là nơi đa số các hoạt động trên Pantheon diễn ra, bạn sẽ thấy rằng có rất nhiều câu lệnh phụ. Dành thời gian để khám phá chúng khi bạn làm việc trên website của bạn, hãy nhìn vào một số cái hữu dụng nhất.

Nếu bạn làm việc ở chế độ SFTP, khi chúng ta đã thực hiện qua đa số của bài hướng dẫn trước đó, bạn sẽ phải commit thay đổi đến version control để lưu chúng và có thể triển khai chúng lên các môi trường Test và Live.

Bạn có thể thực hiện qua CLI, sử dụng lệnh sau đây:

1	$ terminus site code commit --site=<site> --message=<message>

Thay thế <site> với ID của site (ví dụ, tutorial-example-site) và <message> với thông điệp commit mang tính mô tả.

Đồng thời bạn có thể dùng lệnh site code cho chức năng khác có liên quan đến version control. Hãy xem trang giúp đỡ của lệnh đó để có thêm thông tin.

Khi bạn đã commit thay đổi (hoặc push chúng trực tiếp lên version control, nếu bạn ở chế độ Git), bạn có thể triển khai chúng lên Test và Live sử dụng câu lệnh site deploy:

1	$ terminus site deploy --site=<site> --env=<test\|live> [--sync-content] [--cc] [--note=<note>]

Sử dụng câu lệnh này, bạn có thể triển khai từ Dev lên Test hoặc Test lên Live. Để xác định bạn đang làm cái nào, hãy xét thuộc tính --env thành giá trị đúng (test hoặc live). Khi triển khai Test, bạn cũng có chọn lựa để clone data của môi trường từ Live một cách tự động (--sync-content) bỏ qua flag nếu bạn không muốn đồng bộ data. Nếu bạn xác định flag --cc, Pantheon sẽ xoá bộ nhớ đệm sau khi triển khai. Nếu bạn bổ sung ghi chú triển khai, bạn có thể thực hiện điều đó bằng tham số --note.

Để cập nhật upstream của một website đơn lẻ (trong trường hợp của chúng ta, bản cài đặt cơ bản WordPress) thành phiên bản mới nhất, bạn có thể sử dụng câu lệnh:

1	$ terminus site upstream-updates <list\|apply> --site=<site>

Hãy chọn list hoặc chỉ liệt kê các bản cập nhật hoặc apply để chúng diễn ra.

Ngoài những hành động này, bạn có thể dùng terminus site để thực hiện nhiều việc khác như chạy backup, xoá bộ nhớ đệm thủ công, sao chép nội dung giữa các môi trường, và làm việc với nhiều môi trường Multidev. Hãy xem qua trang hướng dẫn cho một danh sách đầy đủ của các câu lệnh và tham số.

Kiểm soát trang WordPress của bạn

Với người phát triển WordPress như bạn và tôi, một sức mạnh quan trọng của Terminus nằm ở chỗ nó cho phép chúng ta chạy các lệnh WP-CLI trên môi trường mục tiêu. Bằng cách này, bạn có thể cài đặt và cập nhật plugin trên site của khách hàng mà không cần phải qua trang dashboard của WordPress.

Câu lệnh để chạy lệnh WP-CLI trên dev server của Pantheon là:

1	$ terminus wp <commands>... [--site=<site>]

Ví dụ để push thay đổi cấu hình từ WP-CFM trên Dev lên Git và sau đó lên môi trường Test (một ví dụ xuất sắc của nhiều vụ lặp lại chỉ chờ đợi được tự động hoá) sử dung Terminus, bạn có thể dùng những lệnh sau đây:

1	$ terminus wp 'config push site_options' --site=tutorial-example-site --env=dev
2	$ terminus site code commit --site=tutorial-example-site --env=dev --message="Pushed configuration changes to site_options.json"
3	$ terminus site deploy --site=tutorial-example-site --env=test --cc --note="Deploy code for options.json configuration"
4	$ terminus wp 'config pull site_options' --site=tutorial-example-site --env=test

Thay thế tutorial-example-site bằng site id thực sự của bạn và site_options với id của chọn lựa bạn đã tạo ra trong WP-CFM.

Khi bạn tiếp tục làm việc với Pantheon và Terminus, tôi chắc bạn sẽ tìm ra nhiều cách hơn để dùng giao diện dòng lệnh giúp tăng tốc và tự động hoá công việc của bạn.

Vậy, hãy tiếp tục trải nghiệm!

2. Bắt đầu kiểm tra trang WordPress của bạn

Trong hướng dẫn trước đó, bạn đã thấy làm cách nào để sử dụng môi trường Test để kiểm tra code của bạn trước khi nó lên Live server cho mọi người sử dụng. Khi đó là một ý tưởng tuyệt vời, hãy chắc rằng bạn đã kiểm tra mọi thứ gồm có checklist và click vào mọi thứ nhiều lần. Nói cách khác, đó thể là một nơi có thể phát sinh lỗi.

Đó là lý do nó là một bước hoàn hảo trong quá trình của bạn để tự động hoá.

Trong phần còn lại của hướng dẫn, chúng tôi sẽ tạo một thiết lập thử nghiệm đơn giản bằng công cụ kiểm tra Behat và làm cho nó tự động chạy mỗi khi bạn triển khai mã của bạn từ Dev để kiểm tra trên Pantheon. Để thực hiện điều này, chúng tôi sẽ sử dụng kết hợp của công tụ scripting Quicksilver trên server của Pantheon và một máy chủ tích hợp liên tục trên cloud.

Chúng ta sẽ bắt đầu thiếp lập các thử nghiệm và chạy nó trên máy tính của bạn.

Bước 1: tạo một dự án mới để tổ chức các thử nghiệm Behat

Behat là một framework mã nguồn mở để phát triển kiểu Behavior-Driven cho PHP, nó cho phép bạn viết test case cho việc kiểm tra trải nghiệm người dùng thực sự phù với mong đợi của bạn.

Hãy bắt đầu thiết lập Behat trong một thư mục mới, sau đó chúng ta có thể triển khai lên server tích hợp liên tục. Các kiểm tra của Behat sẽ chạy nội bộ (sau đó là trên server CI), kiểm tra trang Pantheon đang chạy trên môi trường Test.

Chúng ta sẽ bắt đầu thiết lập Behat bằng cách download một template nhanh chóng từ GitHub và sau đó thay đổi nó cho phù hợp nhu cầu. Trong thư mục thích hợp trên máy của bạn, chạy những lệnh sau đây để tải package về:

1	$ curl https://codeload.github.com/ari-gold/WordPress-Behat-Quickstart/zip/master > WordPress-Behat-Quickstart.zip
2	$ unzip WordPress-Behat-Quickstart.zip
3	$ rm WordPress-Behat-Quickstart.zip

Khi bạn bung nén package, một thư mục mới, WordPress-Behat-Quickstart-master được tạo ra. Đặt tên lại cho thích hợp hơn với mục đích sử dụng:

1	$ mv WordPress-Behat-Quickstart-master wp-pantheon-behat

Sau đó thay đổi vào thư mục:

1	$ cd wp-pantheon-behat

Trong thư mục đó, bạn sẽ tìm thấy một số template cấu hình và 2 tính năng khởi điểm mà bạn có thể xây dựng để tạo kiểm tra Behat của bạn.

Nhưng trước khi bạn nhìn vào họ, hãy hoàn thành bản cải đặt. Bản cài đặt đươc hoàn thành bằng Composer, vậy nếu bạn chưa cài đặt Composer, hãy download và cài đặt nó trước khi tiếp tục.

Một package khởi đầu đã có sẵn cấu hình composer.json và composer.lock để cài đặt Behat, tất cả điều bạn cần là gõ dòng lênh sau vào:

1	$ composer install

Composer sẽ tải về các package cần thiết và lưu chúng vào đúng nơi. Khi chay cài đặt, và hoàn tất, bạn nên nhìn thấy điều giống vậy:

Để chạy Behat, bạn sẽ cần 2 file cấu hình: behat.yml và behat.local.yml.

Dự án đã bao gồm các file mặc định cho cả hai, nhưng file behat.local.yml được lưu thành behat.local.yml.sample để ngăn bạn commit thay đổi cấu hình nội bộ (gồm có các password, ví dụ như Git). Dự án cũng gồm một file .gitignore với behat.local.yml trong đó.

Sao chép cấu hình mẫu:

1	$ cp behat.local.yml.sample behat.local.yml

Bạn có thể sử dụng file này để lưu bất kỳ cấu hình chi tiết của người dùng hoặc môi trường nào, không nên commit trên file behat.yml thực sự. Trong hướng dẫn này, kiểm tra của chúng ta rất đơn giản và chỉ cần bảo đảm file này tồn tại.

Tiếp theo, hãy nhìn vào file cấu hình thừ hai, behat.yml.

Thay đổi file bằng cách thay thế URL được xác định với id base_url bằng URL môi trường test của bạn. Kết quả nên giống như vậy: http://test-tutorial-example-site.pantheonsite.io là URL của server test.

# behat.yml
default:
    extensions:
        Behat\MinkExtension\Extension:
            base_url: http://test-tutorial-example-site.pantheonsite.io/
            goutte: ~
            selenium2: ~
            show_cmd: "/Applications/Firefox.app/Contents/MacOS/firefox %s"


imports:
  - behat.local.yml
  

Khi bạn đã cập nhật cấu hình, kiểm tra mọi thứ làm việc tốt chưa bằng cách liệt kệ những kịch bản test đang có trong thư mục:

1	$ bin/behat -dl

Bạn sẽ thấy một danh sách kịch bản test từ thư mục features:

Giờ hãy nhìn kỹ hơn vào các kiểm tra và chạy trên server kiểm tra của bạn.

Bước 2: Chạy kiểm tra đầu tiên của bạn

Các kiểm tra trên Behat gọi là features, và tôi đã đề cập trước đó, chúng được lưu trong file văn bản trong thư mực features - mỗi file là một feature (tính năng) để kiểm tra.

Nếu bạn nhìn vào thư mục, bạn sẽ thấy hai feature được xác định trong package: homepage_works.feature và blog.feature. Bạn có thể dùng chúng là khởi đầu cho kiểm tra của bạn và sau đó bổ sung nhiều hơn theo ý bạn không khi xây dựng nhóm kiểm tra hoàn chỉnh cho trang WordPress.

Hãy bắt đầu với homepage_works.feature, một kiểm tra nhanh để biết một người khách đến trang của bạn có thể tải trang home:

@smoke
Feature: As a visitor I should be able to load the home page

Scenario: Home page loads
    Given I am on the homepage
    Then I should see "Test with Robots"

Các tính năng Behat được viết bằng một định dạng gọi là Gherkin, như bạn có thể thấy từ đoạn mã này, trông giống như tiếng Anh thuần tuý — có phần trình bày cẩn thận hơn một ghi chú. Hoặc như tài liệu Behat cho biết, "một hình thức mà cả doanh nghiệp và nhà phát triển có thể hiểu rõ ràng."

Trong hướng dẫn này, tôi sẽ không đào sâu vào việc giải thích cách dùng Behat để xây dựng các bài kiểm tra của bạn. Đối với điều đó, tôi khuyên bạn nên đọc tài liệu bắt đầu của Behat.

Cho nhu cầu của chúng tôi tại thời điểm này, đủ để hiểu rằng một tính năng bao gồm một hoặc nhiều Kịch bản, trong đó mô tả cách người dùng hành động và kết quả nên thu được. Điều này không phải là ma thuật. Ở bên dưới, Behat sử dụng regular expression để tham chiếu các bước trong kịch bản của bạn tới các hàm PHP được xác định trong bộ thử nghiệm của bạn (xem các features/bootstrap) hoặc thư viện như Mink - chúng tôi sử dụng nó để mô phỏng một người dùng duyệt web.

Ví dụ, dòng "I am on the homepage" chuyển thành hàm IAmOnHomePage() trong thư viện Mink, và điều hướng đến trình duyệt ảo của Mink để thư mục gốc của website được xác định trong behat.yml - server Test của bạn.

Giờ hãy thay đổi kiểm tra vừa đủ để cho nó vượt qua server test. Thời điểm này, kiểm tra mong tìm ra nội dung "Test with Robots" trên trang chủ. Nói cách khác, trừ khi bạn có văn bản ở đó, nếu không kiểm tra sẽ thất bại.

Vậy hãy thay thế đoạn mã với một câu mà bạn biết sẽ tìm ra trên trang người dùng (ví dụ, tự đề trang của bạn) và lưu thay đổi lại.

Sau đó chạy lệnh sau để thực hiện tất cả kiểm tra được đánh dấu @smoke. Trong trường hợp này, chỉ có một nội dung.

1	$ bin/behat --tags=smoke

Bạn nên xem test pass:

Giờ bạn đã thiết lập một bản kiểm tra chạy thành công trên máy phát triển của bạn, thử nghiệm trang WordPress trên môi trường Test của Pantheon.

Các bản thử nghiệm vẫn còn rất hạn chế, và với server thực sự, đây chỉ là khởi đầu. Vậy sau khi hoàn thành bài hướng dẫn, hãy quay lại bước này, và tìm hiểu kỹ hơn về Behat để tạo ra các kiểm tra thật sự kiểm tra server của bạn, kiểm tra những việc nhỏ đó bạn sẽ tự kiểm bản thân đã kiểm tra trang theo cách thủ công.

Nhưng bây giờ, hãy chuyển sang bước tiếp theo trong hành trình của chúng ta đến phần acceptance test tự động và khiến nó chạy trên cloud.

3. Thực hiện các thử nghiệm Behat của bạn trên cloud

Tích hợp liên tục (Continuous Integration - CI) là thực hành phát triển phần mềm mà trong đó code nhiều lần được merge vào trong nhánh chính và tự động kiểm tra mỗi lần push. Ngày nay, điều này có nghĩa là bạn có một dịch vụ tích hợp liên tục chạy trên cloud đang xem chừng Git Repo của bạn. Sau đó, mỗi khi bạn push một commit mới lên version control, dịch vụ CI sẽ kích hoạt, lấy code từ Git, và tạo bản build và kiểm tra.

Trong hướng dẫn này, chúng ta sẽ sử dụng các phần từ phương pháp này để phát triển một thiết lập phù hợp hơn với quy trình làm việc 3 môi trường Pantheon: thay vì chạy các kiểm tra cho mỗi lần git push, chúng ta sẽ chạy chúng khi code mới được triển khai đến máy chủ Test.

Chúng ta sẽ dùng Circle CI làm server tích hợp liên tục vì nó có một cấp miễn phí đã đủ mạnh cho nhu cầu của hướng dẫn, và một API mà chúng ta có thể gọi từ Pantheon để khởi tạo bản build. Trong triển khai của riêng bạn, bạn cũng có thể dùng một server tích hợp liên tục khác, như Travis CI hoặc Jenkins, với một vài thay đổi đến quá trình được giải thích trong bài hướng dẫn.

Bước 1: Push các kiếm tra lên Git

Đa số các dịch vụ tích hợp liên tục trên cloud được liên kết chặt chẽ với version control, hỗ trợ hoặc Bitbucket hoặc GitHub. Một số hỗ trợ cả hai. Trừ khi bạn thiết lập server CI của riêng bạn, ví dụ như dùng Jenkins, bạn sẽ phải bảo trì một repo tách biệt với tài khoản Pantheon cho thiết lập tích hợp liên tục.

Một chọn lựa sẽ cần bảo trì toàn site ở GitHub hoặc Bitbucket và triển khai nó từ server tích hợp liên tục đến Pantheon sử dụng Terminus. Trong khi nó gần sát với lý tưởng tích hợp liên tục, thì nó cũng phức tạp hơn khi thiết lập - theo ý tôi - nó phá hỏng ý tưởng quy trình công việc của Pantheon.

Đó là lý do trong thiết lập của chúng ta chỉ lưu thiết lập kiểm tra trong repo GitHub được liên kết đến dịch vụ CI và bảo trì code của trang trên Panthean như chúng ta đã làm cho đến giờ.

Đầu tiên, đăng ký GitHub và tạo một repository mới

Sau đó trong thư mục wp-pantheon-behat, khởi tạo Git và commit thay đổi của bạn:

1	$ git init
2	$ git add .gitignore behat.yml composer.json composer.lock features
3	$ git commit -m "First commit"

Chú ý rằng file được cài đặt bởi Composer không được lưu trong git. Chúng sẽ tự động được cài lại trên server CI như một phần của đoạn script.

Sau đó, push dữ liệu lên GitHub repository.

1	$ git remote add origin https://github.com/jarkkolaine/wp-pantheon-behat.git
2	$ git push -u origin master

Thiết lập kiểm tra của bạn giờ đã có trên GitHub. Hãy kết nối nó đến server tích hợp liên tục!

Bước 2: Thiết lập server tích hợp liên tục

Đầu tiên, đăng ký tài khoản miễn phí của Circle CI bằng tài khoản GitHub.

Khi bạn đã đăng nhập, Circle sẽ hỏi bạn chọn một dự án từ GitHub của bạn để build. Ví dụ, ở đây, bạn có thể xem dự án wp-pantheon-behat ở đầu danh sách ở bên phải.

Click vào nút Build Project kế bên dự án.

Circle CI lập tức bắt đầu build. Nó sao chép dự án từ Git, cài đặt thư viên phụ thuộc của Composer, trong trường hợp này là các công cụ kiểm tra từ Behat và sau đó chạy các kiểm tra.

Trong bản build đầu tiên, Circle CI sẽ xuất hiện một lỗi:

An error occurred during composer install

Mặc định, Circle CI chạy phiên bản PHP 5.3.10, quá cũ cho một số thư viện Behat sử dụng. May mắn là việc này rất dễ sửa.

Trong thư mục wp-pantheon-behat, tạo file mới circle.yml. File này sẽ chứa các thay đổi mà chúng ta muốn thực hiện cho cấu hình Circle CI.

Trong file này, bổ sung phần sau đây vào:

1	machine:
2	php:
3	version: 5.5.11

Commit file này lên Git và push lên GitHub repository.

1	$ git add circle.yml
2	$ git commit -m "Added PHP version requirement"
3	$ git push origin master

Sau đó trở về Circle CI, ở đây bạn sẽ thấy hệ thống tích hợp liên tục đã khởi động chạy kiểm tra lại.

Lần này, thiết lập Composer sẽ chạy thành công. Nhưng vẫn còn cần thực hiện vài cấu hình: khi bản build thành công, Circle CI không tìm các kiểm tra của bạn.

Để sửa hãy cho Circle biết cách chạy kiểm tra của Behat.

Trong circle.yml, bổ sung một phần mới, test, ngay bên dưới cấu hình phiên bản PHP chúng ta vừa tạo ra:

machine:
  php:
    version: 5.5.11

test:
  pre:
    - mv behat.local.yml.sample behat.local.yml
  override:
    - mkdir $CIRCLE_TEST_REPORTS/behat
    - ./bin/behat --format junit --out $CIRCLE_TEST_REPORTS/behat --tags=smoke

Hãy xem qua đoạn mã:

Đầu tiên, trong phần pre, chúng tôi yêu cầu Circle CI tạo ra file cấu hình behat.local.yml bằng template trước khi nó cố chạy các kiểm tra.

Sau đó, trong phần có nhãn là override, chúng tôi định nghĩa loạt hành động mà Circle CI cần thực hiện ngay khi chạy các kiển tra.

Lệnh Behat có khác biệt so với khi chúng ta chạy kiểm tra ở máy nội bộ. Đó là vì ta muốn in kết quả kiểm tra trong một file XML có định dạng như JUnit có thể được server CI phân tách. Biến $CIRCLE_TEST_REPORTS là tham chiếu đến một thư mục mà Circle CI muốn tìm thấy các báo cáo kiểm tra.

Commit và push các thay đổi lần nữa và trở lại Circle CI để xác nhận rằng các kiểm tra đã thành công.

4. Sử dụng Quicksilver để khởi tạo Tests lúc Deploy

Giờ bạn đã thiết lập các kiểm tra Behat và chạy chúng trên server tích hợp liên tục, bước còn lại là kết nối cài đặt này với quy trình làm việc của Pantheon bằng cách khiến Pantheon kích hoạt một bản build mới trên Circle CI mỗi khi bạn deploy thay đổi lên môi trường Test.

Chúng ta sẽ thực hiện bằng Quicksilver Platform Hooks của Pantheon, một hệ thống giúp nhà phát triển liên kết các script đến sự kiện trong quy trình của Pantheon.

Kích hoạt bản build mới trên Circle CI chỉ là một ví dụ của điều mà bạn có thể đạt được bằng Quicksilver hook, vì vậy tôi khuyên bạn nên xem qua tài liệu và ví dụ của nó, và nhận ra ra nhiều công dụng hơn.

Bước 1: Xác định hành động Quicksilver

Quicksilver đã được cài đặt trên môi trường Pantheon của bạn, do đó bạn có thể bắt đầu sử dụng băng cách định nghĩa hành động Quicksilver đầu tiên của bạn.

Cấu hình Quicksilver của một trang Pantheon gồm file cấu hình pantheon.yml, nằm ở thư mục gốc code, và script thực sự được viết bằng PHP.

Bạn có thể đăng tải những file này bằng cách dùng SFTP như ta đã thực hiện trong bài hướng dẫn trước, hoặc sử dựng chế độ Git.

Để thực hiện thay đổi trong Git, đầu tiên thiết lập Connection Mode thành Git:

Nhấp vào Git Connection Info để sao chép lệnh để clone git repo của bạn và chạy nó trong thư mục thích hợp trên dòng lênh của bạn:

1	$ git clone ssh://codeserver.dev.XXX@codeserver.dev.XXX.drush.in:2222/~/repository.git tutorial-example-site

Khi lệnh clone đã hoàn thành, thêm file pantheon.yml trong thư mục bằng trình chỉnh sửa văn bản ưa thích của bạn, với nội dung sau đây:

api_version: 1

workflows:
  deploy:
    after:
        - type: webphp
          description: Initiate a new build at Circle CI
          script: private/scripts/circle_ci_notify.php

Trong file cấu hình này, bạn sẽ liệt kệ tất cả script bạn muốn chèn vào quy trình công việc của Pantheon, xác định liệu bạn có muốn script được chạy trước hoặc sau sự kiện đó. Với bất kỳ sự kiện nào, bạn có thể bổ sung bao nhiêu script tuỳ bạn.

Hiện tại, quy trình làm việc dưới đây sẵn sàng để được bổ sung vào:

deploy: kích hoạt khi code của bạn được triển khai lên Test hoặc Live. Script chạy trên môi trường mục tiêu.
sync_code: được kích hoạt khi code được xuất bản thông qua Git hoặc được commit trong dashboard của Pantheon. Script chạy trên môi trường được commit.
clone_database: được kích hoạt khi dữ liệu được sao chép giữa các môi trường. Script chạy trên môi trường mục tiêu.
clear_cahce: được kích hoạt khi bộ nhớ đệm bị xoá. Script chạy trên môi trường đã được dọn sạch.

Mỗi script, hoặc action, gồm có một type (hiện giờ, chỉ có webphp, có nghĩa là code của PHP chạy trên môi trường mục tiêu được hỗ trợ), một description, và một script, môt đường dẫn đến file script có liên quan đến repository code của bạn.

Vậy, xem file pantheon.yml bên trên, bạn sẽ thấy bạn muốn chạy script đó, private/scripts/circle_ci_notify.php, ngay sau khi sự kiện triển khai.

Bước 2: Tạo một PHP script cho hành động Quicksilver

Để hoạt động, hoạt đông Quicksilver hook vẫn cần script.

Script của chúng tôi gọi bản build mới của Circle CI API để chạy bản kiểm tra lần nữa. Chúng ta cần lấy và lưu thông tin Circle CI API theo cách an toàn trong môi trường Pantheon Test.

Trong dashboard Circle CI, nhấp vào Account Settings trên menu bên trái, và sau đó chọn API Tokens để tạo một API Token mới.

Cho bạn một token mới với tên gợi tả và nhấp vào Create new Token.

Giờ bạn có một API token bạn có thể dùng để giao tiếp với Circle CI API.

Commit thông tin bí mật của API hoặc dữ liệu nhạy cảm khác đến version control là một thực hành kém. Vậy hãy sử dụng cách an toàn hơn để chuyển thông tin API đến cho script, bằng cách tạo ra một file cấu hình và upload lên một chỗ an toàn trên server Test.

Trong thư mục bên ngoài repository code đã xuất ra, hãy tạo một file có tên secrets.json. Trong file này, đưa nội dung sau vào:

1	{ "username":"YOUR USER NAME", "project":"wp-pantheon-behat", "token":"YOUR API KEY" }

Sau đó upload lên môi trường test, trong một thư mục có tên files/private, sử dụng SFTP. Chú ý rằng file hệ thông (thư mục files trên server của bạn) được tách biệt ra khỏi code, và các file trong đó không bao giờ đưa lên version control.

Câu lệnh Terminus site connection-info để in ra thông tin kết nối với môi trường của bạn, dựa trên trang, môi trường, và phương thức kết nối bạn truyền vào làm tham số.

Vậy để kết nối vào hệ thống file của môi trường thử nghiệm bằng SFTP, bạn có thể dùng lệnh này - và một mánh khoé nhỏ, hãy bao bọc câu lệnh với dấu (`) để chạy câu lệnh được in ra thay vì chỉ hiển thị nó cho bạn (thông thường, bạn cũng sẽ dùng SFTP client bạn ưa thích.

1	$ `terminus site connection-info --env=test --site=tutorial-example-site --field=sftp_command`

Giờ bạn đã kết nối tới server, đây là lúc upload file cấu hình lên:

1	sftp> cd files
2	sftp> mkdir private
3	sftp> put secrets.json
4	sftp> exit

Thông tin chi tiết đã điền vào. Hãy tạo đoạn script:

Trong repository của code dủa bạn, hãy tạo một thư mục gọi là private/scripts, và bên trong nó, bổ sung một PHP script, circle_ci_notify.php.

Đây là script PHP thông thường để chạy trên môi trường mục tiêu của sự kiện - trong tình huống sự kiện deploy, hoặc Test hoặc Live.

<?php
// Check environment
if ( ! isset( $_ENV['PANTHEON_ENVIRONMENT'] ) || $_ENV['PANTHEON_ENVIRONMENT'] !== 'test' ) {
        die( 'Automatic tests should only be run on the Test environment' );
}

// Load a secrets file
$secrets = _get_secrets('secrets.json');

// Use a curl POST request to trigger the Circle CI API action
$url = 'https://circleci.com/api/v1/project/';
$url = $url . $secrets['username'] . '/' . $secrets['project'] . '?circle-token=' . $secrets['token'];
$curl = curl_init( $url );

// Declare request as a post and setup the fields
curl_setopt( $curl, CURLOPT_POST, true );

// All parameters are optional, so we can send an empty array
curl_setopt( $curl, CURLOPT_POSTFIELDS, json_encode( array() ) );

// Execute the request 
$response = curl_exec( $curl );

if ( $response ) {
        echo "Build Queued";
} else {
        echo "Build Failed";
}

/**
 * Get secrets from secrets file.
 *
 * @param string $file path within files/private that has your json
 */
function _get_secrets( $file ) {
    $secrets_file = $_SERVER['HOME'] . '/files/private/' . $file;
    if ( ! file_exists( $secrets_file ) ) {
        die( 'No secrets file found. Aborting!' );
    }
  
    $secrets_json = file_get_contents( $secrets_file );
    $secrets = json_decode( $secrets_json, 1 );
    
    if ( $secrets == FALSE ) {
        die( 'Could not parse json in secrets file. Aborting!' );
    }
    return $secrets;
}

Hãy xem tỉ mĩ đoạn script từng dòng một.

Dòng 2-5, script xác nhận rằng nó được chạy trên môi trường Test.

Sau đó, dòng 8, nó đọc tham số của API từ file JSON bạn vừa đăng tải lên hệ thống file, sử dụng hàm helper, _get_scerets, được xác định cuối file, dòng 37-50.

Sau đó, dòng 10-22, script gọi HTTP đến Circle CI API để khởi tạo bản build.

Cuối cùng, dòng 24-28, script kiểm tra phản hồi từ API và in ra thông điệp thành công. Nếu bạn thích, đây là lúc nơi để phát triển nhiều hơn: ví dụ bạn có thể cho script đăng một thông báo trên kênh Slack của đội ngũ của bạn.

Giờ bạn đã hoàn tất. Hãy commit và push thay đổi của bạn lên Git.

Khi git push hoàn tất, bạn sẽ thấy kết quả sau đây, Pantheon cho bạn biết rằng nó phát hiện pantheon.yml mới vừa tạo ra của bạn và áp dụng vào môi trường Dev.

remote: 
remote: PANTHEON NOTICE:
remote: 
remote: Changes to `pantheon.yml` detected.
remote: 
remote: Successfully applied `pantheon.yml` to the 'dev' environment.
remote: 
remote: 

Tuy nhiên, như tôi đề cập trước đó, nhiệm vụ deploy được chạy trên môi trường mục tiêu. Vậy trước khi chạy script, chúng ta sẽ cần triển khai thay đổi lên Test.

Hãy làm điều đó bằng giao diện dòng lệnh Terminus (bạn cũng có thể dùng Web Dashboard nếu muốn):

1	$ terminus site deploy --site=tutorial-example-site --env=test --sync-content --note="Added Quicksilver event for Circle CI"

Script của Quicksilver giờ đã sử dụng được trên môi trường Test.

Để xem thực tế kết quả, hãy thay đổi codebase của môi trường Dev (ví dụ như cài đặt một plugin mới hoặc thay đổi child theme của bạn) và commit và deploy (triển khai) thay đổi của bạn lên Test.

Khi bạn đến Circle CI Dashboard, bạn sẽ thấy rằng một bản build mới đã kích hoạt và đang chạy, kiểm tra rằng trang người dùng của Test site đã được tải đúng.

Đồng thời bạn có thể dùng Terminus để kiểm tra đoạn script có chạy đúng không. Để thực hiện điều này, trước khi triển khai thay đổi, trên dòng lệnh, chạy lệnh sau:

1	$ terminus workflows watch --site=tutorial-example-site

Giờ khi quá trình triển khai hoàn tất, bạn sẽ thấy thứ giống như vậy, cho bạn biết về hành động Quicksilver của bạn.

[2016-05-19 13:01:24] [info] Finished workflow b532f7fe-1dc1-11e6-9914-bc764e10b0ce Deploy code to "test" (test) at 2016-05-19 13:01:10
    id: 'b532f7fe-1dc1-11e6-9914-bc764e10b0ce'
    description: 'Deploy code to "test"'
    env: 'test'
    time: '2016-05-19 13:01:10'
[2016-05-19 13:01:26] [info] 
------ Operation: Initiate a new build at Circle CI finished in 3s (test) ------
{
  "compare" : null,
  "previous_successful_build" : {
    "build_num" : 9,
    "status" : "success",
    "build_time_millis" : 55657
  },
  ...

Tổng kết

Thiết lập kiểm tra được tự động giờ đã hoàn thành: bất kể lúc nào bạn triển khai coide từ môi trường Dev của Pathean lên Test, một bản build mới sẽ được kích hoạt trên Circle CI và chạy các kiểm tra Behat trên môi trường Test. Nếu có bất ổn, Circle sẽ gửi bạn email thông báo về bản build đã hỏng vậy bạn có thể sửa nó và thử lại.

Nhưng đây chỉ là khởi đầu.

Trước tiên, bạn sẽ cần viết thêm các kiểm tra. Hãy nghĩ đến điều bạn kiểm tra để bảo đảm site của bạn hoạt động đúng, và sau đó viết các tính năng của Behat để kiểm tra chúng. Sau đó, hãy nghĩ những người thăm trang và khách hàng sẽ sử dụng trang như thế nào, và cũng viết các kiểm tra cho những trường hợp điển hình.

Bạn cũng có thể cải thiện cấu hình của Circle CI, ví dụ bổ sung thông báo Slack về một kiểm tra thành công. Theo cách này, bạn sẽ biết rằng các kiểm tra tự động đã ổn và có thể kiểm tra sau cùng trước khi đưa các thay đổi. Sau đó, một khi bạn tự tin về kiểm tra của mình, có lẽ bạn thậm chí cân nhắc thay đổi circle.yml để dùng Terminus để tự động triển khai code từ Test lên Live sau bản build thành công!

Các khả năng không dừng lại ổ đây! Đồng thời bạn cũng có thể sử dụng Quicksilver để bổ sung thêm các đoạn script để tự động hoá quy trình làm việc của bạn. Hãy xem một vài ví dụ từ các kỹ sư của Pantheon. Sau đó tạo ra thứ của riệng bạn.

Từng chút một, khi bạn tự động hoá quá trình phát triển và kiểm tra của bạn, bạn sẽ tao ra quy trình làm việc càng bảo mật và an toàn.