커피 브레이크 #120. Java 연산자 &, && (AND) || (또는). 개발자를 위한 GitOps 및 DevOps 소개

Java 연산자 &, && (AND) || (또는)

출처: freeCodeCamp Java 프로그래밍 언어에서는 연산자를 사용하여 변수에 대한 작업을 수행합니다. 연산자는 산술 연산자, 할당 연산자, 비교 연산자, 논리 연산자 등 다양한 범주로 나뉩니다. 이번 글에서는 비트 AND 연산자( & )와 논리 연산자 AND( && ), OR( || )에 대해 설명하겠습니다.

비트 AND 연산자를 사용하는 방법

& 기호는 비트 AND 연산자를 나타냅니다. 주어진 숫자의 이진 값을 평가합니다. 이 숫자의 이진 결과는 10진법으로 반환됩니다. & 연산자가 작업을 시작하면 왼쪽부터 시작하여 두 숫자의 문자 값을 평가합니다. 이를 더 잘 이해하는 데 도움이 되는 예를 살펴보겠습니다.

System.out.println(10 & 12);
// returns 8

이것을 어떻게 설명할 것인가? 10의 이진수 값은 1010입니다. 12의 이진수 값은 1100입니다. 연산을 시작하기 전에 고려해야 할 사항은 다음과 같습니다. 1과 0 => 0 0과 1 => 0 1과 1 => 1 0과 0 = > 0 그럼 연산을 해보자. 10의 첫 번째 기호는 1이고 12의 첫 번째 기호도 1이므로 1과 1 = 1입니다. 두 번째 기호로 이동합니다. 10의 경우 0, 12의 경우 1: 1과 0 = 0입니다. 세 번째 기호의 경우 - 10의 경우 1, 12의 경우 0: 1 및 0 = 0. 네 번째 문자의 경우 - 10의 경우 0, 12의 경우 0: 0 및 0 = 0. 이제 반환된 모든 문자를 결합해 보겠습니다. 그러면 1000이 됩니다. 10진수에서 1000이라는 이진 값은 8이므로 연산은 8을 반환했습니다.

논리 AND 연산자를 사용하는 방법

조건을 평가하기 위해 부울 연산자를 사용한다는 점에 유의하세요. 주어진 조건에 따라 true 또는 false를 반환합니다 . && 기호는 AND 연산자를 나타냅니다. 두 개의 문/조건을 평가하고 두 문/조건이 모두 true인 경우에만 true를 반환합니다. 구문은 다음과 같습니다.

statment1/condition1 && statemnt2/condition2

위에서 볼 수 있듯이 문으로 구분된 두 개의 문/조건이 있습니다. 연산자는 두 명령문/조건의 값을 평가하고 결과( 참 또는 거짓) 를 제공합니다 . 예는 다음과 같습니다.

System.out.println((10 > 2) && (8 > 4));
//true

두 조건이 모두 true이므로 작업은 true를 반환합니다 . 10은 2보다 크고 8은 4보다 큽니다. 두 조건 중 하나라도 잘못된 논리가 있는 경우 false를 받게 됩니다 . && 연산자를 더 잘 이해하려면 두 조건이 모두 true여야 true 로 평가된다는 점을 알아야 합니다 . false를 반환하는 또 다른 예는 다음과 같습니다 .

System.out.println((2 > 10) && (8 > 4));
// false

여기서 2는 10보다 크지 않고 8은 4보다 큽니다. 따라서 false 가 됩니다 . 조건 중 하나가 잘못되었기 때문입니다.

• 두 조건이 모두 참인 경우 => 참

• 두 조건 중 하나가 거짓인 경우 => 거짓

• 두 조건이 모두 거짓인 경우 => 거짓

부울 OR 연산자를 사용하는 방법

OR 연산자를 표시하기 위해 || 기호를 사용합니다. . 이 연산자는 두 조건이 모두 거짓인 경우 에만 거짓을 반환합니다. 즉, 두 조건이 모두 true이면 true 가 되고 , 두 조건 중 하나라도 true이면 true 가 됩니다 . 구문은 다음과 같습니다.

statment1/condition1 || statemnt2/condition2

몇 가지 예를 살펴보겠습니다.

System.out.println((6 < 1) || (4 > 2));
// true

조건 중 하나가 true이므로 True가 반환됩니다 .

• 두 조건이 모두 참인 경우 => 참

• 조건 중 하나가 true인 경우 => true

• 두 조건이 모두 거짓인 경우 => 거짓

결론

이 기사에서는 Java에서 비트 & 연산자 와 논리 연산자 && 및 || 를 사용하는 방법을 배웠습니다. . 또한 조건에 따라 각 작업이 반환하는 값도 배웠습니다.

개발자를 위한 GitOps 및 DevOps 소개

출처: Hackernoon DevOps의 주요 목표 중 하나는 개발자가 프로덕션에 기능을 최대한 빠르고 안전하게 배포하도록 돕는 것입니다. 이는 개인 개발 환경 제공부터 프로덕션 워크로드 배포 및 보안에 이르기까지 모든 작업을 수행하는 도구와 프로세스를 만드는 것을 의미합니다. 동시에, 서두르다가 심각한 실패로 이어져서는 안 됩니다. GitOps는 DevOps를 자동화하는 방법입니다. 보다 구체적으로 Git 개발 도구를 사용한 자동화 전략입니다. 개발자는 이미 중앙 집중식 Git 리포지토리(GitHub, GitLab 또는 BitBucket 등을 사용)에 코드를 커밋했으므로 DevOps 개발자는 작업 스크립트를 연결하여 코드가 변경될 때마다 실행할 애플리케이션을 빌드, 테스트 또는 배포할 수 있습니다. 즉, 개발자는 Git만으로 작업할 수 있으며 코드를 프로덕션에 적용하는 데 도움이 되는 모든 것이 자동화됩니다.

왜 GitOps인가?

이전에 DevOps 및 CI/CD 방법은 테스트 실행, 인프라 프로비저닝, 애플리케이션 배포 등 일상적인 작업을 수행하는 독점 스크립트 및 도구 세트였습니다. 그러나 마이크로서비스 아키텍처의 증가와 함께 Kubernetes와 같은 새로운 인프라 도구의 가용성으로 인해 개발자는 CI/CD 프로세스에 더 많이 참여해야 합니다. 이러한 변경으로 인해 사용자 시나리오와 관련된 문제가 발생하여 혼란스럽고 일관되지 않은 워크플로, 노력의 중복 및 개발 속도의 급격한 감소가 발생했습니다. 클라우드 도구와 아키텍처를 활용하려면 팀에는 CI/CD에 대한 일관되고 자동화된 접근 방식이 필요합니다. 이를 통해 개발자는 다음을 수행할 수 있습니다.

• 독점 스크립트 생성 및 유지 관리를 중단하고 대신 범용 프로세스를 사용하십시오.

• 지정된 범용 배포 프로세스를 통해 앱과 서비스를 더 빠르게 구축하세요.

• 코드를 변경한 후 더 빠르게 배포하세요.

• 더 빠르고, 더 자주, 더 안정적인 릴리스를 위해 자동화된 배포를 활성화합니다.

• 선언적 디자인 패턴을 준수하는지 롤백 및 감사를 수행합니다.

개발자는 GitOps를 좋아합니다.

위에서 언급한 모든 이유(및 그 이상)로 인해 기업은 클라우드 애플리케이션 구축 및 유지 관리에 성공하려면 CI/CD 및 DevOps에 대한 관리되고 자동화된 접근 방식이 필요합니다. 그러나 자동화가 전부라면 GitOps가 다른 전략(SlackOps, 예약 배포 또는 단순 스크립트 등)보다 나은 이유는 무엇일까요? 대답은 간단합니다. 개발자는 GitOps를 좋아합니다.

Git - 모든 것을 관리하는 하나의 도구

최근 몇 년 동안 GitOps는 개발자들 사이에서 가장 높은 평가를 받는 DevOps 자동화 전략 중 하나임이 분명해졌으며 그 이유를 아는 것은 어렵지 않습니다. 개발자는 Git에 거주합니다. git에 임시 변경 사항을 저장하고, git을 사용하여 공동 작업하고, git을 사용하여 코드를 검토하고, 모든 변경 사항에 대한 기록과 감사 추적을 git에서도 유지합니다. 개발자들은 Git에 크게 의존하게 되었기 때문에 이를 사용할 수 있는 특별한 도구가 있습니다. CircleCI , Github Actions , Gitlab CI 등과 같이 GitOps를 지원하는 데 가장 자주 사용되는 최신 지속적 통합 시스템에서 파이프라인을 지원하는 구성은 Git 저장소에 직접 위치합니다. 애플리케이션의 소스 코드와 마찬가지로 이러한 구성은 버전이 제어되며 프로젝트에 참여하는 모든 개발자가 볼 수 있습니다. 파이프라인 프로세스가 무엇인지 확인할 수 있을 뿐만 아니라 필요에 따라 빠르고 쉽게 변경할 수도 있습니다. 개발자가 애플리케이션에 대한 테스트를 작성하고 보안과 안정성을 보장할 때 이러한 액세스 용이성은 매우 중요합니다.

완전한 셀프 서비스

새로운 기능이나 버그 수정은 프로덕션에 출시될 때까지 완료된 것으로 간주되지 않습니다. 이는 프로덕션에서 코드 변경이 이루어지지 않도록 하는 모든 것이 개발자의 시간과 에너지를 낭비한다는 것을 의미합니다. 개발자가 자신의 작업 단계를 종료하기 전에 다른 팀이나 사람이 일부 작업을 완료할 때까지 기다려야 한다고 가정해 보겠습니다. 이는 조직 내 마찰과 갈등을 야기할 수 있습니다. 팀 간의 협업을 촉진하는 것은 GitOps의 주요 이점 중 하나입니다. 개발자는 익숙한 도구에서 작업할 수 있을 뿐만 아니라 수동 개입 없이 코드를 프로덕션 환경에 출시할 수도 있습니다. 이는 다른 사람이 자신의 작업을 완료할 때까지 기다리지 않는다는 의미입니다.

모든 일에 지속적인 노력

GitOps의 또 다른 큰 이점은 모든 프로세스가 항상 실행된다는 것입니다! 우리가 수행하는 모든 변경 사항은 수동 단계 없이 테스트 빌드 및 배포를 트리거합니다. 개발자는 GitOps 유무에 관계없이 git을 사용하므로 기존 워크플로에 연결하여 DevOps 프로세스를 실행하는 것은 자동화를 위한 이상적인 옵션입니다.

실제로 GitOps

당연히 프로세스에 개발자가 참여하면서 팀은 Git과 같은 사용자 친화적인 도구를 널리 사용하게 되었습니다. 이는 또한 CI/CD의 통합/배포 단계에 자연스러운 일관성을 제공합니다. 결국 Git 저장소에서 사용할 수 있는 항목(예: 커밋, 풀 요청 열기/닫기, 병합 등)은 제한되어 있으므로 대부분의 GitOps 구현의 모양과 느낌에는 일련의 일반적인 단계가 포함됩니다.

1. 풀 요청, 테스트 및 미리보기 환경

개발자는 새로운 기능에 대한 코드를 작성하는 데 시간을 보낸 후 일반적으로 해당 코드를 새 Git 브랜치에 커밋하고 풀 요청 또는 병합 요청을 리포지토리의 기본 브랜치에 다시 제출합니다. 개발자들은 매일 이런 일을 합니다. 프롬프트에서는 기술 관리자가 코드 변경 사항을 검토하고 이를 기본 애플리케이션 코드에 병합하도록 승인해야 합니다. 이는 DevOps가 추가 작업을 추가할 수 있는 좋은 기회입니다. CI(지속적 통합) 도구를 사용하여 이 풀 요청 프로세스에서 생성된 열기/닫기 이벤트에 연결함으로써 DevOps 팀은 단위 테스트 실행, 미리 보기 환경 생성 및 해당 환경에 대한 통합 테스트 실행을 트리거할 수 있습니다. 이 도구를 사용하면 엔지니어는 코드 변경에 대한 신뢰를 빠르게 구축할 수 있고 제품 ​​관리자는 병합 전 미리 보기 환경을 통해 코드 변경 사항을 확인할 수 있습니다. 더 긴밀한 신뢰는 더 빠른 융합을 의미합니다. 데이터 입력 빈도가 낮을수록 복잡하고 혼란스러운 롤백이 줄어듭니다. 이 GitOps 기술은 더 빠르고 건강한 개발 및 생산 팀의 핵심입니다.

2. 마스터와 병합하고 스테이징에 배포

모든 당사자가 변경 사항을 검토하고 나면 코드는 나머지 개발 팀의 변경 사항과 함께 저장소의 마스터 브랜치에 병합될 수 있습니다. 이 마스터 브랜치는 프로덕션 준비가 거의 완료된 코드의 준비 영역으로 사용되는 경우가 많습니다. 테스트, 배포 등 일부 운영 작업을 완료할 시간은 아직 남아 있습니다. 일반적으로 각 끌어오기 요청을 병합하기 전에 코드를 테스트하지만 테스트를 다시 실행하여 코드가 나머지 팀의 다른 변경 사항과 잘 작동하는지 확인하는 것이 좋습니다. 또한 이러한 모든 변경 사항을 고객에게 릴리스하기 전에 전체 팀이 최신 변경 사항을 검토하고 테스트하는 데 사용할 수 있는 공통 환경("스테이징"이라고 함)에 배포하는 것도 가치가 있습니다.

3. 릴리스를 줄이고 프로덕션에 배포

마지막으로 관리자와 엔지니어가 업스트림 지점의 최신 변경 사항을 검토하고 테스트한 후 팀은 릴리스를 릴리스하고 프로덕션에 배포할 준비가 되었습니다. 이 작업은 배포 스크립트를 실행하고 릴리스를 모니터링하는 작업을 맡은 전담(또는 순환) 팀 구성원인 릴리스 관리자가 수행하는 경우가 많습니다. GitOps를 사용하지 않고 이 팀 구성원은 올바른 스크립트가 어디에 있는지, 어떤 순서로 실행해야 하는지, 스크립트를 실행하는 데 필요한 모든 올바른 라이브러리와 패키지가 컴퓨터에 설치되어 있는지 확인해야 합니다. GitOps를 사용하면 이 배포를 다른 Git 기반 이벤트( 릴리스 또는 태그 생성)에 연결할 수 있습니다. 릴리스 관리자가 해야 할 일은 새로운 "릴리스"를 생성하는 것뿐입니다. 종종 이름으로 semver를 사용합니다. 코드 변경 사항을 빌드하고 배포하는 작업이 자동으로 실행됩니다. CI 도구로 수행되는 대부분의 작업과 마찬가지로 스크립트 위치와 이를 실행하는 데 필요한 라이브러리 및 패키지의 순서로 구성됩니다.

GitOps 도구

강력하고 직관적인 지속적 통합 도구는 이 문서에 설명된 것과 같은 GitOps 프로세스를 계측하는 데 필요한 유일한 도구는 아닙니다. CI 시스템은 git 이벤트를 기반으로 스크립트를 트리거할 수 있지만, 해당 스크립트를 실행하고 쉽고 안전하게 실행하고 유지 관리하려면 여전히 강력한 도구가 필요합니다. 코드 변경 사항 배포(지속적인 전달, CD라고도 함)는 자동화하기 가장 어려운 단계 중 하나입니다. 이것이 바로 GitOps 여정에 도움이 될 수 있는 여러 범주의 도구를 선택한 이유입니다.

Docker를 사용한 컨테이너화

Docker는 클라우드 개발을 완전히 새로운 분산 환경으로 가져왔고 개발자가 마이크로서비스 아키텍처를 실행 가능한 옵션으로 현실적으로 고려하기 시작하도록 도왔습니다. Docker를 강력하게 만드는 것 중 하나는 이전 세대의 가상화 솔루션에 비해 개발자에게 얼마나 편리한지입니다. 우리 리포지토리에 있는 선언적 CI 구성과 마찬가지로 개발자는 컨테이너에 배포된 가상 머신의 자동화된 빌드를 활성화하기 위해 리포지토리에 Dockerfile을 작성하고 유지 관리하기만 하면 됩니다. 컨테이너화는 클라우드 팀에게 매우 강력한 전략이며 레퍼토리의 핵심 도구가 되어야 합니다.

코드형 인프라(IaC)

Dockerfile에 저장되지 않은 인프라를 준비하고 애플리케이션을 배포하는 데에는 많은 노력이 필요합니다. 그 밖의 모든 것에는 Terraform , Cloudformation 등과 같은 IaC(Infrastructure-as-Code) 솔루션이 있습니다 . 이러한 솔루션을 통해 개발자는 Kubernetes 리소스, 로드 밸런서, 네트워킹, 보안 등과 같은 애플리케이션의 다른 부분을 선언적인 방식으로 설명할 수 있습니다. 앞서 설명한 CI 구성 및 Dockerfile과 마찬가지로 IaC 템플릿은 팀의 모든 개발자가 버전을 제어하고 공유할 수 있습니다.