JavaRush /Blog Java /Random-VI /Nghỉ giải lao #120. Toán tử Java &, && (AND) || (HOẶC). G...

Nghỉ giải lao #120. Toán tử Java &, && (AND) || (HOẶC). Giới thiệu về GitOps và DevOps dành cho nhà phát triển

Xuất bản trong nhóm

Toán tử Java &, && (AND) || (HOẶC)

Nguồn: freeCodeCamp Trong ngôn ngữ lập trình Java, chúng tôi sử dụng các toán tử để thực hiện các thao tác trên các biến. Toán tử được chia thành nhiều loại khác nhau: toán tử số học, toán tử gán, toán tử so sánh, toán tử logic, v.v. Nghỉ giải lao #120.  Toán tử Java – &, && (AND) ||  (HOẶC).  Giới thiệu GitOps và DevOps dành cho nhà phát triển - 1Trong bài viết này, chúng ta sẽ nói về toán tử AND theo bit ( & ), cũng như các toán tử logic AND ( && ) và OR ( || ).

Cách sử dụng toán tử bitwise AND

Ký hiệu & biểu thị toán tử AND theo bit. Nó đánh giá giá trị nhị phân của các số đã cho. Kết quả nhị phân của các số này sẽ được trả về cho chúng ta ở cơ số 10. Khi toán tử & bắt đầu công việc, nó sẽ đánh giá giá trị của các ký tự trong cả hai số, bắt đầu từ bên trái. Hãy xem một ví dụ để hiểu rõ hơn về điều này:
System.out.println(10 & 12);
// returns 8
Làm thế nào để giải thích điều này? Giá trị nhị phân của 10 là 1010. Giá trị nhị phân của 12 là 1100. Đây là những gì chúng ta cần xem xét trước khi bắt đầu phép toán: 1 và 0 => 0 0 và 1 => 0 1 và 1 => 1 0 và 0 = > 0 Vậy hãy thực hiện thao tác. Ký hiệu đầu tiên cho 10 là 1, ký hiệu đầu tiên cho 12 cũng là 1, do đó: 1 và 1 = 1. Chuyển sang ký hiệu thứ hai - 0 cho 10 và 1 cho 12: 1 và 0 = 0. Đối với ký hiệu thứ ba - 1 cho 10 và 0 cho 12: 1 và 0 = 0. Đối với ký tự thứ tư - 0 cho 10 và 0 cho 12: 0 và 0 = 0. Bây giờ hãy kết hợp tất cả các ký tự được trả về. Điều này mang lại cho chúng ta 1000. Giá trị nhị phân của 1000 trong cơ số 10 là 8, do đó phép tính của chúng ta trả về 8.

Cách sử dụng toán tử logic AND

Lưu ý rằng chúng tôi sử dụng toán tử Boolean để đánh giá các điều kiện. Chúng trả về đúng hoặc sai tùy thuộc vào các điều kiện nhất định. Ký hiệu && đại diện cho toán tử AND. Nó đánh giá hai câu lệnh/điều kiện và chỉ trả về true nếu cả hai câu lệnh/điều kiện đều đúng. Cú pháp của nó trông như thế này:
statment1/condition1 && statemnt2/condition2
Như bạn có thể thấy ở trên, có hai câu lệnh/điều kiện được phân tách bằng một câu lệnh. Toán tử đánh giá giá trị của cả hai câu lệnh/điều kiện và cho chúng ta kết quả - true hoặc false . Đây là một ví dụ:
System.out.println((10 > 2) && (8 > 4));
//true
Phép toán sẽ trả về true vì cả hai điều kiện đều đúng: 10 lớn hơn 2 và 8 lớn hơn 4. Nếu một trong hai điều kiện có logic không chính xác, chúng ta sẽ nhận được false . Để hiểu rõ hơn về toán tử && , bạn nên biết rằng cả hai điều kiện đều phải đúng để đánh giá là đúng . Đây là một ví dụ khác trả về false :
System.out.println((2 > 10) && (8 > 4));
// false
Ở đây 2 không lớn hơn 10 và 8 lớn hơn 4 - vì vậy chúng tôi nhận được sai . Điều này là do một trong những điều kiện không chính xác.
  • Nếu cả hai điều kiện đều đúng => đúng

  • Nếu một trong hai điều kiện sai => sai

  • Nếu cả hai điều kiện đều sai => sai

Cách sử dụng toán tử Boolean OR

Để biểu thị toán tử OR chúng ta sử dụng ký hiệu || . Toán tử này chỉ trả về sai nếu cả hai điều kiện đều sai. Nghĩa là, nếu cả hai điều kiện đều đúng thì chúng ta sẽ nhận được true , và nếu một trong cả hai điều kiện đều đúng thì chúng ta cũng sẽ nhận được true . Đây là cú pháp:
statment1/condition1 || statemnt2/condition2
Hãy xem xét một vài ví dụ.
System.out.println((6 < 1) || (4 > 2));
// true
Đúng được trả lại cho chúng tôi vì một trong các điều kiện là đúng.
  • Nếu cả hai điều kiện đều đúng => đúng

  • Nếu một trong các điều kiện đúng => true

  • Nếu cả hai điều kiện đều sai => sai

Phần kết luận

Trong bài viết này, chúng ta đã học cách sử dụng toán tử bitwise & và các toán tử logic &&|| trong Java. . Chúng tôi cũng đã tìm hiểu giá trị mà mỗi thao tác trả về tùy thuộc vào điều kiện của nó.

Giới thiệu về GitOps và DevOps dành cho nhà phát triển

Nguồn: Hackernoon Một trong những mục tiêu chính của DevOps là giúp các nhà phát triển triển khai một tính năng vào sản xuất nhanh chóng và an toàn nhất có thể. Điều này có nghĩa là tạo ra các công cụ và quy trình thực hiện mọi việc, từ cung cấp môi trường phát triển riêng đến triển khai và đảm bảo khối lượng công việc sản xuất. Đồng thời, sự vội vàng không được dẫn đến những thất bại nghiêm trọng. Nghỉ giải lao #120.  Toán tử Java – &, && (AND) ||  (HOẶC).  Giới thiệu GitOps và DevOps dành cho nhà phát triển - 2GitOps là một cách để tự động hóa DevOps. Cụ thể hơn, đó là một chiến thuật tự động hóa bằng công cụ phát triển Git. Vì các nhà phát triển đã cam kết mã với kho lưu trữ Git tập trung (sử dụng thứ gì đó như GitHub, GitLab hoặc BitBucket), nên các nhà phát triển DevOps có thể cắm bất kỳ tập lệnh công việc nào của họ để xây dựng, kiểm tra hoặc triển khai các ứng dụng để chạy sau mỗi lần thay đổi mã được thực hiện. Điều này có nghĩa là các nhà phát triển có thể làm việc độc quyền với Git và mọi thứ giúp họ đưa mã vào sản xuất sẽ được tự động hóa.

Tại sao lại là GitOps?

Trước đây, phương pháp DevOps và CI/CD là một tập hợp các tập lệnh và công cụ độc quyền thực hiện các tác vụ hàng ngày: chạy thử nghiệm, cung cấp cơ sở hạ tầng hoặc triển khai ứng dụng. Tuy nhiên, sự sẵn có của các công cụ cơ sở hạ tầng mới như Kubernetes, cùng với sự phát triển của kiến ​​trúc vi dịch vụ, đòi hỏi các nhà phát triển phải tham gia nhiều hơn vào các quy trình CI/CD. Thay đổi này tạo ra các vấn đề liên quan đến kịch bản của người dùng, dẫn đến quy trình làm việc khó hiểu và không nhất quán, nỗ lực trùng lặp và tốc độ phát triển giảm mạnh. Để tận dụng các công cụ và kiến ​​trúc đám mây, các nhóm cần có cách tiếp cận tự động, nhất quán đối với CI/CD. Điều này sẽ cho phép các nhà phát triển:
  • Hãy ngừng tạo và duy trì các tập lệnh độc quyền và thay vào đó hãy sử dụng quy trình chung.

  • Xây dựng ứng dụng và dịch vụ nhanh hơn với quy trình triển khai phổ quát, được chỉ định.

  • Triển khai nhanh hơn sau khi thực hiện thay đổi mã.

  • Cho phép triển khai tự động để phát hành nhanh hơn, thường xuyên hơn và đáng tin cậy hơn.

  • Thực hiện khôi phục và kiểm tra việc tuân thủ các mẫu thiết kế khai báo.

Các nhà phát triển yêu thích GitOps

Vì tất cả các lý do đã nêu ở trên (và nhiều lý do khác), các công ty cần các phương pháp tiếp cận được quản lý và tự động hóa đối với CI/CD và DevOps để thành công trong việc xây dựng và duy trì các ứng dụng đám mây. Nhưng nếu chỉ có tự động hóa thì tại sao GitOps lại tốt hơn các chiến lược khác (như SlackOps, triển khai theo lịch trình hoặc các tập lệnh đơn giản)? Câu trả lời rất đơn giản: các nhà phát triển yêu thích GitOps.

Git - một công cụ để quản lý tất cả

Trong những năm gần đây, rõ ràng GitOps là một trong những chiến lược tự động hóa DevOps được các nhà phát triển đánh giá cao nhất và không khó để hiểu tại sao. Các nhà phát triển sống trong Git. Họ lưu trữ các thay đổi tạm thời trong git, cộng tác bằng git, xem lại mã bằng git, đồng thời lưu giữ lịch sử và dấu vết kiểm tra mọi thay đổi mà bất kỳ ai đã từng thực hiện, kể cả trong git. Bởi vì các nhà phát triển ngày càng phụ thuộc rất nhiều vào git nên có sẵn các công cụ đặc biệt để làm việc với nó. Trong các hệ thống tích hợp liên tục hiện đại thường được sử dụng để hỗ trợ GitOps, chẳng hạn như CircleCI , Github Actions , Gitlab CI và các hệ thống khác, các cấu hình hỗ trợ quy trình được đặt trực tiếp trong kho Git. Giống như mã nguồn của ứng dụng, các cấu hình này được kiểm soát theo phiên bản và hiển thị đối với mọi nhà phát triển làm việc trong dự án. Họ không chỉ có thể xem quy trình quy trình là gì mà còn có thể nhanh chóng và dễ dàng thực hiện các thay đổi khi cần. Sự dễ dàng truy cập này đối với các nhà phát triển là rất quan trọng khi họ viết bài kiểm tra cho ứng dụng của mình và đảm bảo tính bảo mật và ổn định của chúng.

Tự phục vụ đầy đủ

Các tính năng mới hoặc bản sửa lỗi không được coi là hoàn chỉnh cho đến khi chúng được phát hành vào sản xuất. Điều này có nghĩa là bất kỳ điều gì ngăn cản việc thực hiện thay đổi mã trong quá trình sản xuất đều gây lãng phí thời gian và năng lượng của nhà phát triển. Giả sử một nhà phát triển phải đợi một thời gian để nhóm hoặc người khác hoàn thành một số nhiệm vụ trước khi anh ta có thể kết thúc bước công việc của mình. Điều này có thể tạo ra xích mích và xung đột trong tổ chức. Tạo điều kiện cho sự hợp tác giữa các nhóm là một trong những lợi ích chính của GitOps. Các nhà phát triển không chỉ có cơ hội làm việc trên một công cụ quen thuộc mà còn có thể đưa mã của mình vào sản xuất mà không cần can thiệp thủ công. Điều này có nghĩa là họ không chờ đợi người khác hoàn thành nhiệm vụ của mình.

Làm việc liên tục trong mọi việc

Một lợi ích lớn khác của GitOps là tất cả các quy trình luôn chạy! Mỗi thay đổi chúng tôi thực hiện đều kích hoạt quá trình xây dựng và triển khai thử nghiệm mà không cần bất kỳ bước thủ công nào. Vì các nhà phát triển sẽ sử dụng git có hoặc không có GitOps, nên việc kết nối với quy trình làm việc hiện có của họ để chạy các quy trình DevOps là một lựa chọn lý tưởng để tự động hóa.

GitOps trong thực tế

Đương nhiên, sự tham gia của các nhà phát triển vào quá trình này đã dẫn đến việc các nhóm sử dụng rộng rãi các công cụ thân thiện với người dùng như Git. Điều này cũng tạo ra sự nhất quán tự nhiên cho các giai đoạn tích hợp/triển khai của CI/CD. Xét cho cùng, chỉ có rất nhiều thứ có sẵn trong kho Git (ví dụ: cam kết, yêu cầu kéo mở/đóng, hợp nhất, v.v.), vì vậy giao diện của hầu hết các triển khai GitOps đều bao gồm một tập hợp các bước điển hình:

1. Kéo các yêu cầu, kiểm tra và xem trước môi trường

Sau khi các nhà phát triển dành thời gian viết mã cho tính năng mới của họ, họ thường cam kết mã đó với nhánh Git mới và gửi yêu cầu Kéo hoặc Yêu cầu Hợp nhất trở lại nhánh chính của kho lưu trữ. Các nhà phát triển làm điều này hàng ngày. Lời nhắc yêu cầu người quản lý kỹ thuật xem xét các thay đổi về mã và phê duyệt để hợp nhất chúng vào mã ứng dụng chính. Đây là cơ hội tuyệt vời để DevOps bổ sung thêm các nhiệm vụ bổ sung. Bằng cách kết nối với các sự kiện mở/đóng do quy trình yêu cầu kéo này tạo ra bằng công cụ tích hợp liên tục (CI), nhóm DevOps có thể kích hoạt việc thực hiện kiểm thử đơn vị, tạo môi trường xem trước và thực hiện kiểm thử tích hợp đối với các môi trường đó. Công cụ này cho phép các kỹ sư nhanh chóng thiết lập niềm tin vào các thay đổi mã và cho phép người quản lý sản phẩm xem các thay đổi mã thông qua môi trường xem trước hợp nhất. Niềm tin chặt chẽ hơn có nghĩa là sự hợp nhất nhanh hơn. Dữ liệu được nhập càng ít và thường xuyên thì việc khôi phục càng ít phức tạp và khó hiểu. Kỹ thuật GitOps này là chìa khóa giúp các nhóm sản xuất và phát triển nhanh hơn, lành mạnh hơn.

2. Hợp nhất với master và triển khai thành dàn dựng

Khi tất cả các bên đã xem xét các thay đổi, mã có thể được hợp nhất vào nhánh chính của kho lưu trữ cùng với những thay đổi do những người còn lại trong nhóm phát triển thực hiện. Nhánh chính này thường được sử dụng làm khu vực tổ chức cho mã gần như đã sẵn sàng để đưa vào sản xuất. Vẫn còn thời gian để hoàn thành một số nhiệm vụ vận hành như thử nghiệm và triển khai. Mặc dù chúng tôi thường kiểm tra mã cho từng yêu cầu kéo trước khi hợp nhất, nhưng bạn nên chạy lại kiểm tra để đảm bảo mã hoạt động với các thay đổi khác do những người còn lại trong nhóm thực hiện. Bạn cũng nên triển khai tất cả những thay đổi này vào một môi trường chung (được gọi là “tổ chức”) mà toàn bộ nhóm có thể sử dụng để xem xét và kiểm tra những thay đổi mới nhất trước khi chúng được phát hành cho khách hàng.

3. Giảm phát hành và triển khai vào sản xuất

Cuối cùng, sau khi các nhà quản lý và kỹ sư đã có thời gian xem xét và thử nghiệm những thay đổi mới nhất đối với nhánh thượng nguồn, các nhóm đã sẵn sàng phát hành bản phát hành và triển khai vào sản xuất! Nhiệm vụ này thường được thực hiện bởi người quản lý bản phát hành, một thành viên nhóm chuyên trách (hoặc luân phiên) có nhiệm vụ thực thi các tập lệnh triển khai và giám sát bản phát hành. Nếu không sử dụng GitOps, thành viên nhóm này phải kiểm tra xem tập lệnh chính xác ở đâu, thứ tự chạy chúng là gì và liệu tất cả các thư viện và gói chính xác cần thiết để chạy tập lệnh có được cài đặt trên máy của họ hay không. Với GitOps, chúng tôi có thể liên kết việc triển khai này với một sự kiện khác dựa trên Git—tạo bản phát hành hoặc thẻ. Tất cả những gì người quản lý phát hành cần làm là tạo một “bản phát hành” mới, thường sử dụng ngữ nghĩa cho tên. Các tác vụ xây dựng và triển khai thay đổi mã sẽ tự động chạy. Giống như hầu hết các tác vụ được thực hiện bởi công cụ CI, chúng sẽ được cấu hình với vị trí của các tập lệnh cũng như thứ tự của các thư viện và gói cần thiết để chạy chúng.

Công cụ GitOps

Một công cụ tích hợp liên tục mạnh mẽ và trực quan không phải là thứ duy nhất cần thiết để hỗ trợ các quy trình GitOps giống như những quy trình được mô tả trong bài viết này. Hệ thống CI có thể kích hoạt các tập lệnh dựa trên các sự kiện git, nhưng bạn vẫn cần các công cụ mạnh mẽ để chạy các tập lệnh đó và giúp chúng chạy và bảo trì dễ dàng, an toàn. Triển khai thay đổi mã (còn gọi là phân phối liên tục, CD) là một trong những bước khó tự động hóa nhất. Đó là lý do tại sao chúng tôi đã chọn một số danh mục công cụ có thể giúp bạn trên hành trình GitOps của mình:

Container hóa với Docker

Docker đưa việc phát triển đám mây vào một môi trường phân tán hoàn toàn mới và giúp các nhà phát triển bắt đầu coi kiến ​​trúc vi dịch vụ là một lựa chọn khả thi trên thực tế. Một trong những điều khiến Docker trở nên mạnh mẽ là sự tiện lợi của nó đối với các nhà phát triển so với các giải pháp ảo hóa thế hệ trước. Giống như các cấu hình CI khai báo được tìm thấy trong kho lưu trữ của chúng tôi, các nhà phát triển chỉ cần viết và duy trì Dockerfile trong kho lưu trữ của họ để cho phép xây dựng tự động các máy ảo đã triển khai trong vùng chứa. Container hóa là một chiến thuật cực kỳ mạnh mẽ dành cho các nhóm trên nền tảng đám mây và phải là công cụ cốt lõi trong danh mục của bạn.

Cơ sở hạ tầng dưới dạng mã (IaC)

Rất nhiều thứ cần chuẩn bị cơ sở hạ tầng và triển khai các ứng dụng không được lưu trữ trong Dockerfile. Đối với mọi thứ khác, có các giải pháp cơ sở hạ tầng dưới dạng mã (IaC) như Terraform , Cloudformation và các giải pháp khác. Các giải pháp này cho phép các nhà phát triển mô tả các phần khác của ứng dụng, chẳng hạn như tài nguyên Kubernetes, bộ cân bằng tải, mạng, bảo mật, v.v., theo cách khai báo. Giống như cấu hình CI và Dockerfile được mô tả trước đó, mẫu IaC có thể được kiểm soát phiên bản và chia sẻ giữa tất cả các nhà phát triển trong nhóm của bạn.
Bình luận
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION