Jenkins, primi approcci

Cos'è?

Jenkins è un automation server.
Serve quindi per automatizzare task ripetitivi. In particolare è usato per fare il build e il deploy di qualsiasi progetto.

Perché usarlo?

Diciamo che, al primo approccio, me lo sono chiesto anch'io. Cosa può fare Jenkins più di me nel compilare, testare, impacchettare e deploiare un progetto?
In realtà nulla, ma lo fa continuamente e sempre allo stesso modo.
Mi spiego meglio. Le fasi di costruzione di un software di solito sono, dopo la scrittura del codice, la compilazione, (forse) il testing automatico, l'impacchettamento e il deploy (almeno in ambiente di test).
Supponiamo di avere un repository dei sorgenti (Git) e che tutte queste fasi, sulla nostra macchina, funzionino.
Facciamo il commit dei sorgenti e scateniamo il nostro server Jenkins, che sta su una macchina diversa da quella di sviluppo.
Il Job inizia quindi a scaricare i sorgenti e a compilarli, e già qui il processo si blocca perché sembra che manchi un sorgente: ci siamo infatti dimenticati di committarlo, la cosa più normale e che capita con più frequenza (il telefono ha squillato, il collega ci ha chiesto qualcosa, è arrivata una mail urgente, sappiamo tutti come funziona...)
Ecco quindi che Jenkins ha individuato il primo problema, e via via così per tutte le fasi di gestione del nostro software.
Il testing automatico poi è quella fase in cui magari dobbiamo anche avviare una V.M. o un Docker con un db pronto: Jenkins può fare anche questo, sia con plugin dedicati (ce ne sono un fantastiliardo per tutte le esigenze), che lanciando batch o powershell da noi scritti ad hoc.

E ovviamente, può inviarci mail sullo stato del job, se è finito bene, male, con quali errori e in quanto tempo.

Tutto questo aumenta la qualità del nostro codice.
Ovviamente, per il testing, sta a noi implementare un set esaustivo di test: Jenkins non è intelligente, è solo instancabile.

Limiti

Ovviamente non è tutto oro quello che luccica: ho sperimentato Jenkins con .Net, una strana coppia direi, e proprio qui ho visto qualche limite.
In particolare esiste un plugin per compilare via MsBuild, e funziona bene finché si creano build di tipo generico, ma non sono riuscito ad usarlo nelle pipeline (flussi di build), che invece sarebbero stati perfetti per le mie esigenze.

C++ con Visual Studio Code

Cercando un'alternativa per un IDE di sviluppo in C++, mi sono imbattuto nell'articolo di Microsoft su come programmare in C++ con Visual Studio Code

Per questo IDE è stato creato un plugin alla stessa Microsoft che consente l'intellisense del codice.
Il plugin però, come ben specificato, non contiene built-in alcun compiler o debugger, che devono essere installati separatamente.
Non è necessario che il compilatore sia quello Microsoft, anche se il plugin è già pronto a lavorare con questo (ovviamente solo su Windows, non su Linux o Mac), ma possono essere usati anche altri compilatori come ad esempio MINGW, e proprio con quello ho fatto una prova per vedere se tutto funzionava correttamente.

Diciamo subito che non è tutto automatico, tanto che ho dovuto, seguendo le istruzioni, creare sia il file c_cpp_properties.json che il tasks.json per poter compilare. Però, una volta fatto, tutto si risolve con un semplice CTRL+SHIFT+B e la compilazione è fatta!

Certo, una volta compilato, sarebbe bello poter debuggare. Niente di più semplice! Il file launch.json, nel folder .vscode, contiene appunto tutte le configurazioni necessarie per poter debuggare.
Anche in questo caso, seguendo l'articolo, che rimanda alla documentazione del plugin, sono riuscito a creare una configurazione perfettamente funzionante. Anch qui, non è automatico per i nabbi, ma una volta capito il meccanismo il pattern è replicabile all'infinito.

A questo punto sono diventato curioso: e se volessi fare il build tramite makefile?
Il gioco è concettualmente lo stesso: il file tasks,json contiene le configurazioni di progetto: basta modificarlo o aggiungere nuovi task per ottenere il risultato voluto.
Nel mio caso ho modificato il task di build nel seguente modo:

{
  "taskName": "build",
  "type": "shell",
  // "command": "g++",
  "command": "mingw32-make",
  "args": [
    //"-g", "-o", "helloworld", "helloworld.cpp"
  ],
  "group": {
    "kind": "build",
    "isDefault": true
  }
}

In questo modo il task build chiama, invece di g++ con i parametri, il maker: chiamandolo senza parametri il processo cerca ovviamente il file di default, cioè makefile.

E quindi direi che Visual Studio Code potrà essermi molto utile per i miei piccoli esperimenti in C++.

La fine di Windows 10 Mobile

Microsoft ha deciso che il mobile non è più nei suoi piani, ed infatti dismette anche l'idea Windows 10 Mobile.
Ce ne faremo una ragione.

http://www.lastampa.it/2017/10/09/tecnologia/news/microsoft-chiude-lera-di-windows-mobile-negli-smartphone-la-lotta-tra-android-e-ios-fgITmf6MuEsPn0vEbg908O/pagina.html