응용 프로그램의 유일한 진실 출처: 한 번의 재구매에서 모든 자원에 이유를 제공한다

엔지니어들이 a"Single Source of Truth" (SSoT)를 단일 입구점으로 특정 데이터 모델에 접근하는 방법에 대해 이야기하는 것을 자주 들을 수 있다.이것은 조직의Wiki에서 호스트 이름이나 연결 문자열을 검색하고 데이터베이스나 데이터 흐름도에 대한 인용을 찾기 위해 코드 리포를 추적하는 것을 막습니다.물론, 당신은 탐정 일을 한다고 말할 수 있지만, 그것을 버그를 복구할 때까지 남겨 두세요.

그것은 반드시 단일한 점이 아니라 데이터 모델에 따라 분할할 수 있다.IT 부서의 개발자일 경우 사용자 상세 정보용 Active Directory, 워크스테이션용 자산 관리 데이터베이스, 워크스테이션 할당이 있는 네트워크 디바이스 상세 정보 등이 될 수 있습니다. 이러한 데이터베이스 각각은 도메인 또는 특정 컨텐트를 나타내는 데이터 모델입니다.
SOLID 원칙, 특히 "단일 책임 원칙"을 따른다면 코드에서도 이 점을 깨닫게 될 것입니다.

"There should never be more than one reason to change" or "every class should have only one responsibility"

다시 말하면 하나의 논리는 한 가지 일/한 분야만 책임져야 한다.만약 네가 한 군데만 논리가 있는 것이 아니라면, 그것을 그들 자신의 모듈이나 함수로 분해해라.이것도 DRY principles의 핵심 개념이다.
이러한'단일 책임'사고는 SsoT의 핵심으로 많은 문제를 해결했다. 그러나 내가 보기에 가장 큰 두 가지 문제는 다음과 같다.

반복 작업: 모든 유형의 자원(인원 시간, 위탁 관리, 문서, 재무, 서비스 등)을 유지하고 변경할 수 있는 작업이다.

인위적인 실수: 피할 수 없는 일이다.인간과 기계의 상호작용이 발생할 수 있는 실례 수량을 줄이면 데이터의 부정확한 횟수를 줄일 수 있다.데이터 모델에 대해 이것은 데이터 모델 구조나 데이터 입력일 수 있다.믿을 만한 원칙에 대해 말하자면, 이것은 한 곳에서 잘못 실현된 기능이나 잘못된 복구일 수도 있고, 모든 곳에서 일치하지 않을 수도 있다.

응용 프로그램은 어떻게 그 안에 융합됩니까?

응용 프로그램을 배치하는 예시를 보십시오.물론 모든 응용 프로그램은 다르고 구조가 다르기 때문에 나는 간단함을 유지할 것이다.
우리는 곧 발표될 기능이 하나 있는데, 우리는 그것을 배치해야 한다.다음 단계를 따르겠습니다.

특성을 개발하고 분기 또는 주간의 PR을 발표할 준비를 한다.여기에는 기능의 셀 테스트 및 API/구조 문서가 포함됩니다.

이 기능은 귀하의 기초 구조에 새로운 자원을 추가해야 하기 때문에 기초 구조 코드(IaC) 구현에 대한 변경을 요청합니다.이것은 코드 심사 과정을 거쳐 개발자와 DevOps팀의 조율 아래 각 환경에 배치해야 한다.

코드 검토는 개발·품질보증 단계까지 구축을 추진하고 UAT에 대비한다.이제 새로운 기능을 포함하여 Wiki(Confluence, Git* 페이지 등)에 액세스하여 사용 기능을 변경할 수 있습니다.

코드 검토를 받고 변경 사항을 생산으로 미룹니다.

너는 진실의 근원은 다음과 같다고 말할 수 있다.

코드 리콜(소스 코드),

위키(문서용),

CI/CD 파이프(장치 테스트, 구축 및 배포용) 및

IaC(프로비저닝용)

이런 이해의 문제는 하나의'원천'의 변화가 다른 원천의 변화에 달려 있다는 것이다.이것은 상술한 문제를 두드러지게 했다.

같은 팀이나 여러 팀이 여러 곳에서 조치를 취해야 하기 때문에 중복 작업을 한다.

인위적인 오류를 도입하는 것은 이러한 '출처' 중 하나가 잊혀지거나 어떤 기능과 무관하다는 판정을 받을 수 있기 때문이다.

잘못된 도입의 원인은 우리가'단일 진실의 출처'의 중점, 즉'영역의 출처'가 아니라'원천'에 관심을 갖는 것을 소홀히 했기 때문이다.이런 상황에서 필드는 응용 프로그램이다.

중앙 집중식 애플리케이션/도메인 논리

이제 애플리케이션/도메인에 대한 세부 정보를 하나의 소스로 통합하면 어떤 일이 발생합니까?

특성을 개발하고 분기 또는 주간의 PR을 발표할 준비를 한다.여기에는 장치 테스트, IaC 변경, 이 기능의 API/구조 문서, AscidActor/Markdown/RST 등Wiki 문서가 포함됩니다.

Pipeline은 PR을 획득하고 기능 코드, IaC 및 문서 구문에 따라 유닛 테스트를 실행합니다.

코드 심사는 개발과 품질 보증을 통해 기능을 추진한다.각 단계는 IaC를 환경에 적용하고 업데이트된 환경에 기능 구축을 배치합니다.코드 검토 프로세스에는 Dev, DevOps, SecOps 등의 구성원이 참여할 수 있습니다.

UAT/Production 단계에서 확장 옵션을 사용하여 문서를 Wiki에 전송한다(대부분의 문서 해석기는 주요 Wiki 공급자, 예를 들어 ConfluenceMark for Markdown, Official AsciiDoctor Exporter와 RST Exporter) 또는 DocBook/eBook/PDF로 해석하여 발표한다.

이 두 과정 사이에 주의해야 할 변화 중 하나는 인류의 상호작용과'시스템에 들어가는'절차의 감소이다.파이핑 처리 모든 업데이트 작업.저장소를 보는 경우 업데이트된 모든 파일을 리포의 일부로 사용합니다.

project
 |- doc/
     |- index.ad
     |- usage.ad
 |- infra/
     |- app.yml (ansible playbook)
     |- main.hcl (terraform project)
 |- pipeline/
     |- main.yml
     |- env_template.yml
 |- project/
     |- lib/
         |- ...
     |- project.(py|ts|...)
CONTRIBUTORS.md
CHANGELOG.md
README.ad
USAGE.ad
...

또 다른 큰 변화는 우리가 어떻게 우리의 파이프에서 많은 단계 문을 실현하여 비인공 검사를 응용하여 코드의 질을 검증하는가이다.코드 심사 기간에 고려해야 할 일이 더 적고 생산 환경에 더 빨리 배치될 수 있다는 뜻이다.

고려 요소

물론 우리가 하는 모든 일에는 부정적인 영향이 있기 때문에 이런 부정적인 영향을 이해하는 것이 중요하다.이것은 다를 것이 없으니 우리는 그것을 한쪽에 놓아야 한다.

더 많은 전기 투자: 이 일이 순조롭게 진행되도록 하기 위해서 우리는 이 책임을 맡을 수 있도록 대량의 일을 해야 한다.하지만 투자를 투자라고 부른다. 전기에 걸린 시간은 앞으로 임무를 반복하는 시간이 더 적다는 것을 의미하기 때문이다.즉,

Wiki에 콘텐츠를 쓰거나 IaC provisioner

와 통합할 수 있는 서비스 계정/토큰을 만듭니다.

검사와 단위 테스트를 수행하는 파이프를 작성

정보를 수집하는 파이프 임무를 수행하여 단계문을 간소화한다

연결 문자열과 파이프에 대한 기밀 처리 접근 권한

디자인 테스트 세트는 응용 프로그램 테스트를 실행할 뿐만 아니라 모든 다른 유형의 테스트도 실행해야 한다.

유연성이 비교적 낮다. 이 과정의 긴밀한 집적 정도에 따라 원형, 배치와 문서의 유연성도 상응하여 떨어진다.

'빠른 복구' 가 없습니다. 우리는 이미 이 방대한 파이프 프로세스를 실현했기 때문에 타자 오류를 복구하기 위해 한 줄의 변경 사항을 만드는 것은 '구축과 배치' 처럼 간단하지 않습니다.그것은 네가 이미 새로운 기능을 실현한 것처럼 모든 같은 검사를 실행해야 한다.

이러한 차이점에 대해 다음을 수행합니다.

철저한 코드 심사: 파이프는 많은 도구와 실천 과정을 실현하여 코드 심사 과정을 자동화할 수 있다.노인과 지도자들이 관심을 가져야 할 일에 집중할 수 있다는 뜻이다.전기 작업도 단계별로 완성할 수 있고 배치 과정이 파이프에 기록되면서 천천히 세워진다.

더 빠른 생산 시간: 우리는 코드 평가의 많은 임무를 자동화했기 때문에 우리는 언제든지 그것을 실행할 수 있고 필요할 때만 인공 기반 단계의 관문을 요청할 수 있다.이것은 기능의 출시 속도를 몇 주에서 며칠, 심지어 몇 시간으로 높일 수 있다.

빠른 복구는 가능합니다. 빠른 복구는 여전히 완료할 수 있기 때문에 인용부호에 이 점을 덧붙입니다.파이프는 여전히 철저할 것이지만, 우리는 파이프의 운행 속도에 따라 빠른 복구를 내놓을 수 있다.또 하나 주의해야 할 것은 파이프가 정상적으로 작동한다면 우리는 '빠른 복구' 가 이미 과거의 수준이 되어야 한다는 것이다.

니 생각을 알려줘.우리는 모두 자신의 차이가 있는데, 나는 여기에 내가 생각하지 못했던 고려가 있다고 믿는다.서로 다른 과정을 시도하는 것부터 완전히 다른 기대 아래 일하는 것까지 이것은 (주어진 시간에) 매우 칭찬받고 환영받는 과정이다.