kmadof / seirios

MIT License
0 stars 0 forks source link

Jakie stosować podejście do build pipeline? #1

Open kmadof opened 4 years ago

kmadof commented 4 years ago

Które z poniższych podejść stosować przy tworzeniu buildów:

Gutek commented 4 years ago

rozwiń proszę master skrypt?

kmadof commented 4 years ago

Przykładowo, kiedy tworzymy pipeline dla aplikacji napisanej w dotnet core to możemy to zrobić w ten sposób:

steps:

- task: DotNetCoreCLI@2
  displayName: Restore nuget packages
  inputs:
    command: restore
    projects: '**/*.csproj'
    workingDirectory: $(rootDirectory)

- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '$(rootDirectory)/*.sln'
    arguments: '--configuration $(buildConfiguration)'

# You just added coverlet.collector to use 'XPlat Code Coverage'
- task: DotNetCoreCLI@2
  displayName: Test
  inputs:
    command: test
    projects: '*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration) --collect:"XPlat Code Coverage" -- RunConfiguration.DisableAppDomain=true'
    workingDirectory: $(rootDirectory)

- task: DotNetCoreCLI@2
  inputs:
    command: custom
    custom: tool
    arguments: install --tool-path . dotnet-reportgenerator-globaltool
  displayName: Install ReportGenerator tool

- script: ./reportgenerator -reports:$(Agent.TempDirectory)/**/coverage.cobertura.xml -targetdir:$(Build.SourcesDirectory)/coverlet/reports -reporttypes:"Cobertura"
  displayName: Create reports

- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage'
  inputs:
    codeCoverageTool: Cobertura
    summaryFileLocation: $(Build.SourcesDirectory)/coverlet/reports/Cobertura.xml  

albo napisać skrypt (powershell/bash) w którym wykonujemy te kroki czyli

dotnet restore
dotnet build
dotnet test

etc

A po stronie serwera CI tylko uruchomić ten skrypt.

W moim odczuciu może to mieć sens przy skomplikowanych konfiguracjach, kiedy tak naprawdę i tak potrzebujemy jakieś skryptu żeby zautomatyzować proces kompilacji (i ewentualnie uruchomienia aplikacji) lokalnie. Jednak są też minusy tego podejścia, zastosowanie cache dla paczek nuget po stronie Azure DevOps może być wówczas trudniejsze.

Jestem ciekaw jakie jest Twoje zdanie na ten temat,

kmadof commented 4 years ago

Po rozmowie z @Gutek mogę dodać, że nie ma sensu robić master skryptu dla samego master skryptu. Zależy nam na niezależnym wdrażaniu poszczególnych aplikacji i jeżeli one potrzebuję skryptu to master skrypt może być w konsekwencji kompozycją tych mniejszych. Tyle tylko, że ma to służyć tworzeniu środowiska lokalnego, a nie jako pipeline. Tutaj zależy nam na niezależności wdrożen poszczególnych aplikacji.