In qualità di product owner, potremmo ritrovarci nella condizione di dover monitorare l'avanzamento dei lavori su più repository contemporaneamente. Le issue di GitHub sono suddivise, per l'appunto, per repository, ma creando un Project e configurandolo opportunamente, è ...

I workflow di GitHub possono essere usati anche per eseguire dei processi ricorrenti che, per esempio, aggiornano le anagrafiche di alcune persone su base giornaliera, calcolano dei dati aggregati per generare dei report e così via. Spesso, queste operazioni, si basano sull'uso ...

Quando si lavora in progetti molto complessi, è probabile che per mantenere i costi non ci siano sufficienti runner/agent assegnati per garantire che tutte le policy (ad esempio le pipeline/workflow per compilare il nostro codice). Questo implica che i workflow potrebbero essere ...

Talvolta potrebbe tornarci comodo poter fermare l'esecuzione di un workflow sotto determinate condizioni. Immedesimandoci in un caso reale, potremmo voler far fermare una esecuzione automatica di un progetto .NET Core quando la soglia minima della code coverage non è stata ...

In GitHub si possono creare le release per tenere traccia dello stato delle applicazioni in un certo istante temporale e per rilasciare a tutti gli effetti ai clienti "finali" qualcosa che possono utilizzare e che è considerato stabile. Tuttavia, all'interno di una release ci ...

Nell'ottica di semplificare i processi e condividere il più possibile il codice per riutilizzarlo in altri scenari, nascono i re-usable workflow in GitHub, che sono particolarmente utili quando la nostra applicazione è distribuita su più repository. Per esempio, quando ...

Uno dei problemi più comuni che ci si ritrova ad affrontare quando si lavora in ambienti estremamente complessi ed automatizzati delle enterprise, è che spesso abbiamo configurato decine o centinaia di workflow automatici, ma difficilmente ci sono delle azioni che vengono ...

Orchestrare il deployment di un'applicazione non è mai semplice, in quanto sono coinvolti diversi attori. Il più importante è sicuramente l'architettura del software, in quanto il rilascio di un sistema a microservizi è certamente più complesso di un sistema a monolite, ma ...

In Kubernetes abbiamo decine di risorse che possiamo controllare tramite la CLI. Molte di queste risorse sono immediatamente disponibili una volta fatto l'apply del file di manifest mentre, per altre, è necessario attendere un certo periodo. In questo articolo vedremo come ...

Per questioni di compliance e security, molto spesso è necessario garantire che tutte le immagini di Docker che poi finiranno in un cluster di Kubernetes provengano da container registry "fidati". Tra questi ci possono anche essere alcuni endpoint pubblici, che non richiedono ...