API는 개발에서 생산까지 - 섹션 9 - SCA

16734 단어 csharp github dotnet docker

시리즈 소개

이 블로그 시리즈의 9부에 오신 것을 환영합니다. 가장 기본적인 예로부터 시작하겠습니다.net5 웹api 및 개발에서 생산까지의 과정.Azure, Docker, GitHub, GitHub 작업을 사용하여 CI/C 배치를 진행하고 인프라 시설을 Pulumi를 사용하는 코드로 사용할 것입니다.
이 문서에서 주목할 사항은 다음과 같습니다.

정적 코드 분석(SCA)

TL；박사 01 명

정적 코드 분석은 개발에서 생산 과정까지의 중요한 단계이다.기능 개발 등 다른 주기로 이어진다.시장에 많은 공구가 있으니 틀림없이 너에게 적합한 것이 있을 것이다.코드코프.io가 유용하다는 것이 증명되었지만 코드 덮어쓰기에만 적용됩니다. 다음 단계에서SCA와 코드 덮어쓰기를 사용하면 API 제품이 이득을 얻을 수 있습니다.

Quality should never take a back seat when building mission critical systems.

GitHub 저장소

방울방울 / 견본일기예보 제9부분

이 저장소는 블로그 글 시리즈의 일부로 API가 개발부터 생산에 이르기까지 9부분에서 개발에 이르기까지표준에 기초하다.net 표준 날씨 API 샘플.

요구 사항

에서 끝나는 지점을 계속할 것입니다. 이것은 귀하가 GitHub Repo - Part 8의 최종 결과를 시작으로 삼아야 한다는 것을 의미합니다.
만약 당신이 이 시리즈에 계속 관심을 가지고 있다면, 나는 당신을 이렇게 하도록 격려할 것입니다. 그러나 이전의 댓글이 당신에게 이미 지식이 되었다면, 필요 없습니다.

소개하다.

우리는 정적 코드 분석을 연구하고 있는데 이것은 우리가 개발에서 생산 과정에서 반드시 갖추어야 할 또 다른 분석이다.현재 많은 도구가 있는데 셀프 위탁 관리에서 SaaS까지 저에게 있어서 저는 더 적은 도구를 관리하는 것을 좋아하고 SaaS 솔루션을 선택했습니다.이것은 당연히 네가 반드시 이렇게 해야 한다는 것을 의미하지 않는다.나는 네가 시장에 무엇이 있고 무엇이 너의 수요를 만족시킬 수 있는지 검사해 보라고 강력하게 건의한다.
우리는 CodeCov에게 손을 흔들며 작별을 고할 것입니다. 심각한 빈틈이 있습니다. 이 here 와 here 에 대한 정보를 더 많이 읽을 수 있습니다.그러나 마이그레이션은 이 때문이 아니라 SCA 및 코드 덮어쓰기를 제공하는 SaaS 솔루션과 통합되기 때문입니다.)

We will be integrating with Code Climate Quality

우리 시작합시다!

첫걸음

그들의 사이트로 가다→ 우수한 제품으로 이동하여 클릭→ 시작하자.코드 Climate Quality를 GitHub 응용 프로그램으로 등록합니다.
이 여정을 마치면, 모든 공공 저장소의 목록을 볼 수 있습니다.

두 번째 단계

네가 선택한 환매 협의를 더하면 우리의 경우, 이것은 Samples.WeatherForecast-Part-9 이다.
선택한 저장소를 선택하면 Code Climate Quality 가 실행됩니다. 잠시 기다려 주십시오. 차 한잔 드세요:)

Code Climate Quality가 구축 및 스캔 작업을 완료하면 다음과 같은 작은 팝업 창이 표시됩니다.

세 번째 단계

저장소 대시보드로 이동합니다.

Checkout the stats - They look pretty good so far!

유지보수 가능 레벨이 현재 A라는 것을 알 수 있습니다. 단, 코드 커버율이 없습니다.

4단계

코드 덮어쓰기를 복구합시다.
현재, 코드 기후 품질은 그들의 문서에 있거나 기술적으로 C#가 지원된다는 것을 설명하지 않았다.슬픈 얼굴: (
하지만 이렇게 빨리 포기하지 말자. supported code coverage formats봐봐. 우리는 마땅히...표지: D
본 시리즈 블로그에서 알 수 있듯이 우리가 현재 사용하고 있는 것은lcov이고 우리도 생성할 수 있다Cobertura.지원되는 형식입니다.
우리는 lcov 파일에 코드 품질을 제공해야 한다. 이직한 코드Cov에 대한 것처럼 (GitHub 작업 흐름에서 코드Cov를 삭제하는 것을 잊지 마라.)

단계 4.1

기후 품질 코드로 이동→ 당신의 환매 협의→ 재구매 설정→ 덮어쓰기 비율을 테스트합니다.
너는 너를 보게 될 것이다. TEST REPORTER ID 우리는 이것을 우리의 GitHub 기밀 구역에 두어야 한다.

You should know how to do this by now, put it into your secrets for your repo and call it, CC_TEST_REPORTER_ID.

단계 4.2

GitHub Action CI 워크플로우의 새 단계를 추가합니다.
CodeCov를 제거하거나io 또는 작업 단계 전/후 다음 코드를 입력합니다.

- name: Code coverage [Code Climate]
  uses: paambaati/[email protected]
  env: 
    CC_TEST_REPORTER_ID: ${{secrets.CC_TEST_REPORTER_ID}}
  with:
    coverageLocations: ${{ github.workspace }}/path/to/artifacts/testresults/coverage.info:lcov
    prefix: /code/

We have the environment set to our test reporter id so it know which repo in Code Climate Quality to link it to.

We've specified the coverage file, please note that there is a, :lcov at the end to state that it is indeed an lcov file.

The prefix parameter is purely required because of how we have built with Docker.

접두사는 테스트 보고서의 sub-commands 를 가리킬 수 있다.
Dockerfile에서 코드를 컴파일할 때 Docker의 로컬 디렉터리로 복사하거나, 나처럼 /code 작업 디렉터리를 WORKDIR /code 로 설정한 다음 코드를 복사하고 구축하는 것이 필요하기 때문입니다.이것은 lcov 파일의 모든 경로가 /code를 가리킨다는 것을 의미한다.그러나 GitHub 저장소에는 디렉토리가 없습니다.
다행히도, 이 문제에 있어서, 나는 약간의 잘못을 저질렀다

다섯 번째 단계

커밋을 수행하거나 CI 워크플로우만 트리거합니다.
코드 기후 품질을 계속 작성하십시오. 대시보드에 코드 커버율 통계 데이터가 있어야 합니다. 아래와 같습니다.

6단계

코드 기후 품질에는 GitHub 로봇이 하나 있다.
우리 안배하자...
클릭→ 설정(요청 주석 끌어오기)

GitHub 응용 프로그램 설치...

설정한 권한을 확인합니다...

고르다→ 새로운 문제에 대해 별도의 내연 평론을 발표하다

열다→ 내연 문제 평론

일곱 번째 단계

우리는 몇 가지 뚜렷한 문제를 제기함으로써 코드 환경의 질을 테스트하고 그것이 어떻게 처리되는지 볼 수 있으며 개발자의 체험도 테스트할 수 있다.

7.1단계

수정prefix: /code/개변→ WeatherForecastController.cs방법...

[HttpGet]
public IEnumerable<WeatherForecast> Get()
{
    var rng = new Random();

    var temps1 = Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateTime.Now.AddDays(index),
        TemperatureC = rng.Next(-20, 55),
        Summary = Summaries[rng.Next(Summaries.Length)]
    })
    .ToArray();

    var temps2 = Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateTime.Now.AddDays(index),
        TemperatureC = rng.Next(-10, 45),
        Summary = Summaries[rng.Next(Summaries.Length)]
    })
    .ToArray();

    return Enumerable.Concat(temps1, temps2);
}

All we've done here is duplicate the amount of responses, but it's slightly different. Take note of the TemperatureC value in each. Hopefully this will be caught by Code Climate Quality as a duplication.

단계 7.2

다음 수정에 대해 Get() 파일을 변경하겠습니다.
덧붙이다→ 새 부동산 이름은 WeatherForecast.cs이다.

public int TemperatureFahrenheit  => 32 + (int)(TemperatureC / 0.5556);

This is identical, except for the property name, hopefully Code Climate Quality will pick this up as a duplication also.

8단계

당신의 모든 변화에 대해 PR을 제출하세요. 당신의 새로운 CI 작업 절차에서 코드 기후의 질이 취하는 행동을 보아야 합니다.

As you can see from the image above, the Code Climate Quality GitHub Bot has made inline comments as it found a duplication, whoohoo!

However, don't jump for joy just yet, as this is the only duplication found, it seems it has not picked-up on the property body duplication :(

아홉 번째 단계

GitHub 상태 점검을 활성화합니다.
기후 품질 코드로 이동→ 당신의 환매 협의→ 재구매 설정→ github→ 끌어오기 요청 상태 업데이트→ 편집을 클릭합니다.→ 열다

GitHub로 돌아가 저장소로 이동→ 나뭇가지→ 분기 규칙→ 다음 항목을 검토하여 GitHub에서 필요한 사항을 확인하십시오.

코드 환경 품질의 한 가지 편리한 점은 GitHub뿐만 아니라 제품 자체의 문제를 볼 수 있기 때문에 두 가지 보기를 볼 수 있다는 것이다.

PR을 다시 제출하면 GitHub 상태 검사의 빛이 사방으로 비치는 것을 볼 수 있습니다. 주의하십시오. 저는 여전히 CodeCov를 가지고 있습니다.io는 거기에 있지만, 다음 게시물에서 사라집니다.

상태 검사가 진짜/가짜 - 코드 환경의 질이 중복된 문제를 표시한 것을 감안하여 코드 라이브러리에 대한 영향을 승인해야 합니다.이 예에 대해 나는 비준할 것이다. 이렇게 하면 우리는 무슨 일이 발생했는지 볼 수 있다.

This is a key moment to take note of, by using this workflow we can easily assess the impact and approve or deny, keeping track of codebase health has now never been more simple :)

코드 기반 영향

우리가 예상한 바와 같이, 우리는 일을 더욱 나빠지게 했다.우리는 코드를 복제하여 우리의 유지보수성이 떨어졌기 때문에 우리의 등급은 A에서 B로 떨어졌다.물론 우리의 테스트 범위도 떨어졌다.

기술 채무관

코드 환경의 질에 대한 좋은 시각은 기술 채무도이다. 해석 시간과 모든 면에서 보존되어야 하지만, 나는 그것이 때때로 얼마나 유용한지 확실히 보았다.

저희가 뭘 배웠죠?

우리는 왜 정적 코드 분석이 중요한지, 그리고 SaaS 도구(예를 들어 코드 환경의 질)를 사용하여 최적화된 작업 흐름이 공사 팀의 일상생활에 어떻게 영향을 미치는지 이해했다.이것은 생산 과정의 일부로서 유지보수성과 코드 커버율 등 요소를 모르는 상황에서 발표하면 생산 과정에서 문제가 생기기 쉽고 특히 임무 관건형 시스템에 문제가 생기기 쉽다.
유지보수성과 테스트 범위율을 이해하는 것은 제품 공학팀의 제품 품질에 매우 중요하다.