Home Blog

Deploy di un’applicazione Laravel su Kubernetes – Parte 1

0

Oggi voglio iniziare una mini-serie di articoli dedicati al deploy di un’applicazione Laravel su un cluster Kubernetes. 

Era un po’ che volevo farlo: imparare quello che ho imparato per me è stato molto stimolante e mi ha portato un sacco di benefici. Anche economici.

Prima di iniziare però voglio subito mettere un paio di cose in chiaro:

  • non sarà un tutorial “passo dopo passo”: ogni applicazione ha le sue necessità, le sue peculiarità e può necessitare di un setup totalmente diverso da quello che ho messo su io. Per questo motivo, racconterò la mia esperienza, cosa ho fatto e come ho risolto alcuni dei miei problemi, con l’obiettivo di fornire una traccia da seguire per chi si sta avvicinando ora all’argomento;
  • non sono un esperto di Kubernetes: le soluzioni che ho trovato funzionano perfettamente per me, anche se non è detto siano il meglio possibile. Trovo l’argomento molto affascinante ma NON sono ad un livello di conoscenze avanzato sotto questo punto di vista. Non aspettatevi un corso accelerato di Kubernetes su queste pagine!

Quello che leggerete sarà, insomma, un po’ un “diario” della mia esperienza.

Creare un Admin per Laravel con Orchid CRUD. Ecco com’è andata

1

Torno di nuovo a scrivere di Orchid, il progetto di Alexandr Chernyaev dedicato alla costruzione di pannelli di amministrazione con Laravel. Sto continuando ad usarlo e, devo ammetterlo, mi ci sto appassionando.

Il progetto è ben fatto, funziona bene ed ha una logica che mi piace molto.

Ho provato Orchid per Laravel. Posso farci un Pannello di Amministrazione?

1

In questi giorni ho passato un po’ di tempo a guardarmi intorno, alla ricerca di alternative a Laravel Nova per quanto riguarda la costruzione di pannelli di amministrazione con Laravel. Fino ad oggi, infatti, ho usato solo Nova e devo dire di essermi trovato davvero bene.

Sono però anche una persona molto curiosa: perché limitarmi? Così, tra una sbirciata a Reddit (quanta roba interessante che ci trovo!) e ricerche su Google, alla fine sono incappato in un progetto abbastanza particolare: Orchid.

Una “Bestia Strana”

Devo aggiornare la mia app Laravel, oppure no?

0

Ieri, girovagando come al solito tra le discussioni in cerca di idee, ho trovato un post interessante che parlava di come e quando aggiornare un’app Laravel. Mi ha sorpreso molto trovare pareri di ogni tipo:

  • “no, ma figurati, non aggiornare se non è strettamente necessario”
  • “aggiorna sempre!”
  • “io aggiorno solo ad ogni LTS”

… e così via.

Mi sono ricordato che ultimamente ho avuto un’esperienza ravvicinata del terzo tipo con un aggiornamento abbastanza “importante” di un’app Laravel.

Ho pensato di scrivere questo articolo per “riassumere” un po’ questa esperienza, nella speranza che possa essere utile anche ad altri.

Come usare (e non usare) i Seeder in Laravel

1

Qualche giorno fa ho pubblicato un articolo sulle migration in Laravel che ha suscitato molto interesse, più di quanto mi aspettassi. Nel pubblicarlo in giro, in tanti mi hanno fatto qualche domanda sui Seeder.

Se le migration sono uno strumento molto usato ma poco compreso nel profondo, i Seeder vengono adoperati sensibilmente meno. Onestamente, non ne capisco nemmeno il perché, vista la loro comodità.

In questo articolo parlerò un po’ di di Seeder, di come funzionano e di quanto mi hanno aiutato nel lavoro di tutti i giorni.

Come usare (e non usare) le Migration in Laravel

1

Da stamattina ho in testa di scrivere un articolo che parli di uno strumento che ritengo molto importante: le migration in Laravel, uno tool potentissimo che troppo spesso viene usato male.

Durante questo periodo di feste, infatti, ne ho lette di tutti i colori su gruppi, forum e così via. Ho deciso, quindi, di buttare giù qualche considerazione e darvi qualche consiglio che avrei voluto ricevere io, la prima volta che le ho studiate.

Prima di tutto, cosa sono?

Come la documentazione a riguardo ci suggerisce, le migration sono una sorta di sistema di versioning per il nostro database. Nelle migration c’è la storia del nostro database e viene spiegato il modo in cui questo è evoluto nel tempo. 

Usare ASDF per installare diverse versioni di PHP, insieme!

0

Qualche giorno fa, parlando di Laravel Sail ed ambienti di sviluppo, ho scritto di quanto sia interessante (ed importante) avere un environment semplice da installare e configurare quando lavoriamo con i nostri progetti.

Quante volte, però, capita di aver bisogno di fare una “prova al volo”?

Magari vogliamo solo provare un nuovo package, oppure testare del codice senza troppi fronzoli. Niente database, Redis o altro. Giusto il runtime di quel linguaggio, magari in una versione specifica.

La soluzione di cui abbiamo bisogno è…

Asdf?

Per questi casi, uso uno strumento che si chiama asdfNo, non ho premuto i primi tasti a caso sulla tastiera, si chiama davvero così. Asdf è un tool che permette di installare in locale una o più versioni specifiche di qualsiasi dei linguaggi supportati. Mi piace per tre motivi:

Creiamo un ambiente di sviluppo Docker per i nostri progetti con Laravel Sail!

1

Oggi vorrei spendere due parole a proposito di qualcosa a cui tengo molto: l’ambiente di sviluppo in cui lavoriamo ai nostri progetti. Sembra una cosa scontata ma non è assolutamente così: non avete idea di quante app vedo, ancora oggi, costruite in ambienti che non aiutano minimamente lo sviluppatore… anzi!

Qualche giorno fa vengo a sapere che hanno rilasciato una piccola perla: Laravel Sail, come package ufficiale! Sail configurare, con uno sforzo minimo, un ambiente di sviluppo chiavi in mano, dockerizzato, personalizzabile ma comunque facilissimo da usare. Il tutto con uno strumento da linea di comando a corredo.

(Sail prende spunto da una mia vecchia conoscenza: Laravel Vessel.)

Oggi vi dirò:

  • perché bisognerebbe usare sempre un buon ambiente di sviluppo, magari dockerizzato;
  • come installare ed usare Laravel Sail con un progetto Laravel;

Setup PHPUnit Tests on Pull Request for Laravel with GitHub Actions

0

Recently, Github released Actions beta for developers to let them try it.

Github actions are a way to automate your workflow in many ways. You can use some events triggers to do something. These events can be anything like a branch push, pull request open/push, and so on. I will not dig deeper into this now because it’s not the scope of my article.

github actions

via.

However, when discovering them, I asked myself: Can I use it to run PHPUnit tests on my Pull Requests, to avoid using external tools like Travis CI? I love Travis but hey, let’s play with it.

The answer is yes. Here is how I did it and how I created a workflow for it.

But first, some basics.

What is a Workflow?

A Workflow is an automated process you can create to tell Github that it must do something when something else happens. This may involve everything like testing, building, deploying, and so on. Workflows are stored under the .github/workflows directory in your repository, as .yml files.

Once they are versioned in the repo, Github will read them, validate them, and finally run them when the specified condition is triggered.

Ok, how do I make it?

I will copy/paste mine and then explain it.

Note: this is specific to Laravel. My app uses the 5.8 version of the framework.

Note 2: I prepared a .env.testing file with some specific settings I want to use when running PHPUnit.

Let’s see what we have:

  • name: no need to explain it. It’s just the name I gave to the workflow;
  • on: this is the condition you want to check to fire the workflow. In my specific case, I wanted to trigger a test run at every pull request open/push, to link this action launch as a condition to let me merge my PR branch (more details here);

At this point, I put my job inside the jobs item of the file. I named it run-tests. This is not something standard, and you can choose the name you want here.

Let’s see what we have inside a single job item:

  • runs-on: ok, here we can specify the OS we want to run our tests on. I use Ubuntu 18.04 in my production environment, so I decided to use the same while running tests;
  • container: here, we can select the container we want to run our tests on. I decided to use this prooph/composer image to have everything I need for a Laravel app. I used the 7.2 version to reflect what I have in production;
  • services: here, you can specify some extra services to be used during tests. In my specific case, I added a Redis instance because I have some functional tests that I need to cover a complete use case of my app;

The preparation part is done. Now…

The Steps

Steps are the most atomic part of your workflows. As you can see from the snippet, they are a sequence of commands I run to prepare everything and, finally, run tests.

The only exception is the first one, uses/checkout. You can find more about it here: https://github.com/actions/checkout.

And that’s it!

The icing on the cake: Github will automatically add the status check for every pull request from this moment on, and will re-run tests at every push on your branches (if a related PR is open).

Hope you will enjoy it!

La Comunicazione – Creare un Negozio con Shopify – Il mio Primo Anno

1

Questo articolo è parte di una serie che ho scritto per raccontare di tutto quello che ho imparato nel mio primo anno da Shopify owner. Clicca qui per l’indice.


Dopo aver parlato del prodotto, adesso tocca parlare di quello che ho imparato riguardo la comunicazione con i propri clienti (e non solo). Nel corso dell’ultimo anno, infatti, mi è capitato di parlare con tantissime persone. A volte per una lamentela, per un problema con la logistica, a volte per ricevere un complimento o sorridere leggendo una risposta in dialetto.

(è un gioco di parole: “San Ceppat”, cioè “si è inceppato”. Le pallotte sono un piatto tipico della nostra regione)

Ogni parola è importante

Mi è capitato di rispondere a domande di potenziali clienti curiosi, letteralmente, ad ogni ora del giorno. Ogni singola ora del giorno, dalle sette di mattina a mezzanotte. A volte non sono riuscito a rispondere sul momento, com’è normale che sia (siamo pur sempre esseri umani con una vita) ma in linea di massima occorre ricordare un principio tanto semplice nella sua essenza quanto semplice da scordare: ogni singola parola che rivolgiamo a qualcuno che ci scrive è un biglietto da visita.

Sempre, senza eccezioni. Dall’altra parte c’è qualcuno che è interessato e probabilmente vuole comprare la tua merce. Ha già fatto un passo, un bel passo: dagli una mano. Come? Ecco qualche spunto: