Przejdź do treści

📑 Blog

DRAFT: DOTNET - Przygotowanie skryptów deweloperskich

Artykuł jest w postaci notatki

#!/usr/bin/env bash
set -euo pipefail

# load credeantials
source .env

# NU1603 - https://learn.microsoft.com/pl-pl/nuget/reference/errors-and-warnings/nu1603
ARGS="--packages $NUGET_PACKAGES --verbosity minimal -p:WarningsAsError=NU1603"

# Jeśli masz problem z nugetproxy
ARGS+="--disable-parallel"

# https://learn.microsoft.com/pl-pl/dotnet/core/tools/dotnet-nuget-add-source
dotnet nuget add source $PROXY_NUGET_URL --name "$PROXY_NUGET_SOURCE" --username "$PROXY_NUGET_USERNAME" --password "$PROXY_NUGET_PASSWORD" --store-password-in-clear-text
if [$? -ne 0]; then
    echo "Source add $PROXY_NUGET_SOURCE error"
else
    echo "Source $PROXY_NUGET_SOURCE is added"
fi

dotnet nuget disable nuget.org
if [$? -ne 0]; then
    echo "Source disabled 'nuget.org' error"
else
    echo "Source 'nuget.org' is disabled"
fi

# Znajdź wszystkie pliki solucji i przywróć pakiety
find . type f --name "*.sln" |while read -r sln; do
    dotnet restore $sln $ARGS
    if [$? -ne 0]; then
        echo "Dotnet restore failed for $sln"
    else
        echo "Dotnet restore successful for $sln"
    fi  
done

ANSIBLE - Testowanie ról Ansible z użyciem Molecule i Proxmox

Molecule to framework umożliwiający automatyczne testowanie ról Ansible w odizolowanych środowiskach. W integracji z Proxmox pozwala na dynamiczne tworzenie maszyn wirtualnych na podstawie istniejących szablonów (VM Templates), uruchamianie roli Ansible, a następnie walidację jej działania.

Proces testowania obejmuje:
1. Klonowanie nowej VM na serwerze Proxmox z predefiniowanego szablonu.
2. Provisioning – uruchomienie roli Ansible i konfiguracja systemu.
3. Weryfikację poprawności konfiguracji za pomocą testów Ansible lub Testinfra.
4. Usunięcie instancji po zakończeniu testów, aby nie pozostawiać zbędnych zasobów.

Dzięki temu testowanie ról Ansible w Proxmox jest szybkie, powtarzalne i zautomatyzowane, co pozwala na wykrywanie błędów jeszcze przed wdrożeniem na produkcję. 🚀

Architektura rozwiązania

architektura-test-role

VSCODE - Developowanie projektów terraform z użyciem kontenera

Niniejszy wpis stanowi kontynuację poprzedniego artykułu: VS Code – Automatyczne uruchamianie kontenera MkDocs przy starcie projektu

Info

W tym materiale omówiono, jak skonfigurować środowisko Visual Studio Code do pracy z projektami Terraform w kontenerze Docker, w tym:

  • automatyczne pobieranie tagów obrazu Dockera z GitLab Container Registry,
  • uruchamianie planów Terraform z poziomu kontenera,
  • bezpieczne uwierzytelnianie przy użyciu klucza SSH i dostępu do prywatnych modułów.

VSCODE - Developowanie projektów packer z użyciem kontenera

Niniejszy wpis stanowi kontynuację poprzedniego artykułu: VS Code – Automatyczne uruchamianie kontenera MkDocs przy starcie projektu

Info

W tym materiale omówiono, jak skonfigurować środowisko Visual Studio Code do pracy z projektami Packer w kontenerze Docker, w tym:

  • automatyczne pobieranie tagów obrazu Dockera z GitLab Container Registry,
  • uruchamianie planów Terraform z poziomu kontenera,
  • bezpieczne uwierzytelnianie przy użyciu klucza SSH i dostępu do prywatnych modułów.

VSCODE - Automatyczne uruchamianie kontenera MkDocs przy starcie projektu

W tym artykule pokazano, jak skonfigurować Visual Studio Code tak, aby uruchamiał kontener MkDocs bezpośrednio z poziomu zadania (task), uruchamianego ręcznie lub automatycznie.

Info

Wielu twórców dokumentacji technicznej korzysta z MkDocs, aby wygodnie budować i serwować strony dokumentacyjne w oparciu o Markdown. Kiedy projekt dokumentacji rozwijany jest lokalnie, warto zadbać o to, aby środowisko uruchamiało się automatycznie wraz z otwarciem projektu – najlepiej w kontenerze Dockera.

Conventional Commits

Conventional Commits1 to konwencja nazewnictwa wiadomości commitów, która wprowadza porządek, czytelność i automatyzację do historii projektu. W tym artykule pokażę Ci, jak działa, dlaczego warto ją wdrożyć i jak zacząć.

PACKER - template vm na proxmox - alpine

Dziś pokażę, jak utworzyć template wirtualnej maszyny na proxmox za pomocą packera

Czemu tworzymy template maszyny wirtualnej?

Tworzenie template'u maszyny wirtualnej na Proxmox za pomocą Packer ma wiele zalet, zwłaszcza w kontekście automatyzacji i zarządzania infrastrukturą jako kodem (IaC). Oto kluczowe powody, dla których warto to robić:

  • Automatyzacja i Powtarzalność
  • Standaryzacja Środowiska
  • Łatwa Integracja z Terraform
  • Bezpieczeństwo i Aktualizacje
  • Optymalizacja Zasobów
  • Łatwiejsza Skalowalność
  • Integracja z CI/CD

GITLAB-CI - Infrastruktura procesów gitlab-ci

Info

W dzisiejszym artykule przedstawię, jak zorganizować i zautomatyzować procesy CI/CD w GitLab, bazując na strukturze projektu, który implementuje różne komponenty i etapy pipeline'u. Omówię kluczowe elementy, takie jak analiza statyczna kodu, testy jednostkowe, walidacja konfiguracji, budowanie artefaktów oraz wdrażanie aplikacji. Wszystko to z pominięciem katalogu _old, który zawiera przestarzałe lub zarchiwizowane dane.

Kod źródłowy projektu znajduje się tutaj.

SONARQUBE - Integracja z SonarQube cloud

SonarQube to narzędzie do analizy jakości kodu, które pomaga wykrywać błędy, podatności bezpieczeństwa i problemy związane ze stylem oraz technicznym długiem w kodzie źródłowym. Obsługuje wiele języków programowania i integruje się z popularnymi narzędziami CI/CD, takimi jak GitLab CI, Jenkins czy GitHub Actions. SonarQube oferuje statyczną analizę kodu, raporty z oceną jakości oraz wskazówki dotyczące poprawy kodu. Może działać zarówno lokalnie, jak i w środowisku serwerowym, wspierając zespoły w utrzymaniu wysokiej jakości oprogramowania.