Strumenti DevOps

Scegli gli strumenti per ogni fase del ciclo di vita DevOps.


Toolchain aperta

DevOps rappresenta l'evoluzione delle metodologie Agile, un cambiamento culturale che riunisce i team di sviluppo e operativi, una pratica che implica un cambiamento culturale, nuovi principi di gestione e strumenti tecnologici che aiutano a implementare le best practice.

In fatto di toolchain DevOps, le organizzazioni dovrebbero cercare strumenti che migliorino la collaborazione, riducano i passaggi da un contesto all'altro, introducano l'automazione e sfruttino l'osservabilità e il monitoraggio per rilasciare software migliori, più velocemente.

Gli approcci alla toolchain DevOps sono principalmente due: toolchain all-in-one oppure aperta. Una soluzione DevOps all-in-one è una soluzione completa che di solito non si integra con altri strumenti di terze parti. Una toolchain aperta può essere personalizzata in base alle esigenze di un team che utilizza strumenti diversi. Atlassian ritiene che una toolchain aperta sia l'approccio migliore in quanto può essere personalizzata con strumenti all'avanguardia in base alle esigenze specifiche di un'organizzazione. L'uso di questo approccio spesso determina una maggiore efficienza in termini di tempo e riduce il time-to-market.

Scopri di più sulle toolchain DevOps.

Indipendentemente dal tipo di toolchain DevOps scelta da un'organizzazione, un processo DevOps deve utilizzare gli strumenti giusti per gestire le fasi chiave del ciclo di vita DevOps:

  • Pianifica
  • Compila
  • Continuous integration e continuous deployment
  • Monitoraggio
  • Funzionamento
  • Feedback continuo

Con una toolchain Open DevOps, gli strumenti selezionati gestiscono più fasi del ciclo di vita DevOps. Le sezioni seguenti mostrano alcuni degli strumenti più diffusi per DevOps; tuttavia, considerata la natura del mercato, questo elenco cambia spesso. I provider aggiungono nuove funzionalità che consentono loro di includere più fasi del ciclo di vita DevOps, ogni trimestre vengono annunciate nuove integrazioni e, in alcuni casi, i provider consolidano le loro offerte per concentrarsi su un problema specifico dei loro utenti.

Pianifica


Logo di Jira Software Logo di Confluence Logo di Slack

Seguendo le indicazioni del manuale Agile, consigliamo strumenti che consentano ai team di sviluppo e operativi di suddividere il lavoro in blocchi più piccoli e gestibili per accelerare le distribuzioni. In questo modo è possibile ricevere prima le indicazioni degli utenti e ottimizzare un prodotto in base al feedback ricevuto. Cerca strumenti che offrano funzionalità di pianificazione dello sprint e monitoraggio dei ticket, e che supportino la collaborazione, come Jira.

Un'altra pratica eccellente consiste nel raccogliere continuamente il feedback degli utenti, organizzarlo in input utilizzabili e dare priorità a tali azioni per i team di sviluppo. Cerca strumenti che favoriscano il "brainstorming asincrono" (se lo desideri). È importante che tutti possano condividere e commentare qualsiasi aspetto: idee, strategie, obiettivi, requisiti, roadmap e documentazione.

Inoltre, non dimenticare le integrazioni e i flag delle funzionalità. Ovunque tu decida di definire l'ambito della funzione o del progetto, questo dovrebbe essere convertito in storie utente nel tuo backlog di sviluppo. I flag di funzionalità sono istruzioni if presenti nella base di codice che consentono ai team di attivare e disattivare le funzioni.

Per ulteriori informazioni su questa fase, dai un'occhiata questo post dei product manager di Atlassian sul backlog grooming e sulla definizione delle priorità.

Plan


Jira Software logo Confluence logo Slack logo

Taking a page out of the agile handbook, we recommend tools that allow development and operations teams to break work down into smaller, manageable chunks for quicker deployments. This allows you to learn from users sooner and helps with optimizing a product based on the feedback. Look for tools that provide sprint planning, issue tracking, and allow collaboration, such as Jira. 

Another great practice is continuously gathering user feedback, organizing it into actionable inputs, and prioritizing those actions for your development teams. Look for tools that encourage “asynchronous brainstorming” (if you will). It’s important that everyone can share and comment on anything: ideas, strategies, goals, requirements, roadmaps and documentation.

And don’t forget about integrations and feature flags. Wherever you decide to scope your feature or project, it should be converted into user stories in your development backlog. Feature flags are if-statements in the code base that enable teams to turn features on and off.

For more on this phase, check out this post from Atlassian product managers about backlog grooming and prioritization.

Compila


Logo di Kubernetes Logo di Docker

Ambienti di sviluppo identici a quelli di produzione

Mentre Puppet e Chef sono utili soprattutto per i team operativi, gli sviluppatori utilizzano strumenti open source come Kubernetes e Docker per eseguire il provisioning di singoli ambienti di sviluppo. La codifica a fronte di repliche di produzione virtuali e monouso aumenta la produttività.

Quando tutti i membri del team lavorano da ambienti che sono stati sottoposti a provisioning in modo identico, la frase "Sul mio computer funziona!" non suscita più l'ilarità perché è vera.

Logo di Ansible Logo di Chef Logo di Docker Logo di puppet Logo di Terraform

Infrastructure as a Code

Gli sviluppatori si adoperano per creare applicazioni modulari perché sono più affidabili e di facile manutenzione. Quindi, perché non estendere questo modo di pensare all'infrastruttura IT? Ciò può essere difficile da applicare a sistemi che sono in continua evoluzione. Quindi, aggiriamo l'ostacolo usando il codice per il provisioning.

Il concetto di Infrastructure as code indica che il re-provisioning è più veloce della riparazione, nonché più coerente e riproducibile. Questo significa anche che è possibile implementare facilmente varianti del proprio ambiente di sviluppo con una configurazione simile a quella di produzione. Il codice di provisioning può essere applicato e riapplicato per collocare un server in una baseline nota. Può essere memorizzato nel controllo della versione. Può essere testato, integrato nella CI (continuous integration) e sottoposto a peer review.

Quando la conoscenza istituzionale è "codificata nel codice", i manuali e la documentazione interna nono sono più necessari. Ciò che emerge è costituito da processi ripetibili e sistemi affidabili.

Logo di Bitbucket Logo di Github Logo di GitLab

Controllo del codice sorgente e codifica collaborativa:

È importante avere il controllo del codice sorgente. Gli strumenti disponibili per tale controllo aiutano a memorizzare il codice in diverse catene in modo da poter visualizzare le singole modifiche e condividerle per agevolare la collaborazione. Anziché attendere l'approvazione delle modifiche prima della distribuzione in produzione, puoi migliorare la qualità e il throughput del codice con peer review eseguite tramite pull request.

Che cosa sono le pull request? Le pull request comunicano al tuo team le modifiche che hai inviato a un branch di sviluppo nel tuo repository. Il team può quindi esaminare le modifiche proposte e discuterne prima di integrarle nella riga di codice principale. Le pull request aumentano la qualità del software, il che si traduce in un minor numero di bug e imprevisti, riducendo i costi operativi e velocizzando lo sviluppo.

Gli strumenti di controllo del codice sorgente dovrebbero integrarsi con altri strumenti, il che consente di collegare le diverse parti dello sviluppo e della distribuzione del codice. Questo permette di sapere se il codice della funzione è in esecuzione nella produzione. Se si verifica un imprevisto, è possibile recuperare il codice per chiarire la dinamica dell'evento.

Continuous integration e continuous delivery


Logo di Jenkins Logo di AWS Logo di Bitbucket Logo di CircleCIlogo di Snyk Logo di SonarSource

Continuous integration

La continuous integration è la pratica di archiviare il codice in un repository condiviso più volte al giorno e di testarlo ogni volta. In questo modo, puoi rilevare automaticamente i problemi in anticipo, correggerli nelle fasi iniziali e distribuire nuove funzioni agli utenti il prima possibile.

La revisione del codice eseguita tramite pull request richiede la creazione di branch e va di moda. La stella polare della metodologia DevOps è un flusso di lavoro che determina branch più veloci e meno numerosi e mantiene il rigore dei test senza sacrificare la velocità di sviluppo.

Cerca gli strumenti che applicano automaticamente i tuoi test ai branch di sviluppo e ti offrono la possibilità di eseguire il push a quello principale quando le build dei branch hanno esito positivo. Inoltre, ricevi un feedback continuo tramite avvisi di chat in tempo reale forniti dal tuo team con una semplice integrazione.

Scopri come Bitbucket Pipelines ti aiuta ad automatizzare il codice dal test alla produzione.

Logo di mabl Logo di Sauce Labs Logo di Xray Logo di Zephyr

Test

Gli strumenti di test soddisfano molte esigenze e funzionalità, tra cui l'esecuzione di test esplorativi, la gestione dei test e l'orchestrazione. Tuttavia, per la toolchain DevOps, l'automazione è una funzione essenziale. I test automatizzati danno i loro frutti nel tempo poiché accelerano i cicli di sviluppo e di test a lungo termine. Inoltre, in un ambiente DevOps è importante per un altro motivo: la consapevolezza.

L'automazione dei test può aumentare la qualità del software e ridurre i rischi se viene eseguita sin dall'inizio e con una frequenza elevata. I team di sviluppo possono eseguire ripetutamente test automatici, coprendo diverse aree come test dell'interfaccia utente, scansione di sicurezza o test di carico. Inoltre, producono report e grafici di tendenza che aiutano a identificare le aree a rischio.

Il rischio è un dato di fatto nello sviluppo di software, ma non è possibile mitigare ciò che non si può prevedere. Dai una mano al tuo team operativo e lascia che dia un'occhiata ai meccanismi interni insieme a te. Cerca gli strumenti che supportano le wallboard e consenti a tutti i partecipanti al progetto di commentare risultati specifici di build o distribuzione, meglio ancora se si tratta di strumenti che semplificano il coinvolgimento del team operativo nei test blitz e nei test esplorativi.

Logo di Jira Software

Dashboard delle distribuzioni

Una degli aspetti più stressanti del rilascio di software è acquisire in un'unica posizione tutte le informazioni su modifiche, test e distribuzione per un rilascio imminente. L'ultima cosa di cui si ha bisogno prima di un rilascio è una lunga riunione sullo stato. È qui che entrano in gioco le dashboard di rilascio.

Cerca strumenti con un'unica dashboard integrata con il repository di codice e gli strumenti di distribuzione. Trova una soluzione che ti offra visibilità completa di branch, build, pull request e avvisi di distribuzione in un'unica posizione.

Logo di Bitbucket Logo di Zephyr

Distribuzione automatizzata

Per la distribuzione automatizzata non esiste una ricetta magica che funzioni per ogni applicazione e ambiente IT. Tuttavia, un metodo comunemente utilizzato prevede la conversione del runbook delle operazioni in uno script eseguibile tramite comando usando Ruby o Bash. Le buone pratiche di progettazione sono fondamentali. Usa le variabili per distinguere i nomi host: mantenere script o codice univoci per ogni ambiente non è affatto semplice (e non sempre rientra tra gli obiettivi). Crea metodi di utilità o script per evitare la duplicazione del codice e sottoponi gli script a peer review per un controlli di integrità.

Prova innanzitutto ad automatizzare le distribuzioni nel tuo ambiente di livello più basso, dove utilizzerai l'automazione più frequentemente, quindi replicale fino alla produzione. Se non altro, questo esercizio mette in evidenza le differenze tra gli ambienti e genera un elenco di task per standardizzarli. Inoltre, la standardizzazione delle distribuzioni attraverso l'automazione offre l'ulteriore vantaggio di ridurre la "desincronizzazione" server all'interno e tra gli ambienti.

Test


Automated testing

               

Testing tools span many needs and capabilities, including exploratory testing, test management, and orchestration. However, for the DevOps toolchain, automation is an essential function. Automated testing pays off over time by speeding up your development and testing cycles in the long run. And in a DevOps environment, it’s important for another reason: awareness.

Test automation can increase software quality and reduce risk by doing it early and often. Development teams can execute automated tests repeatedly, covering several areas such as UI testing, security scanning, or load testing. They also yield reports and trend graphs that help identify risky areas.

Risk is a fact of life in software development, but you can’t mitigate what you can’t anticipate. Do your operations team a favor and let them peek under the hood with you. Look for tools that support wallboards, and let everyone involved in the project comment on specific build or deployment results. Extra points for tools that make it easy to get Operations involved in blitz testing and exploratory testing.

Deploy


Deployment dashboards

Jira Software logo 

One of the most stressful parts of shipping software is getting all the change, test, and deployment information for an upcoming release into one place. The last thing anyone needs before a release is a long meeting to report on status. This is where release dashboards come in.

Look for tools with a single dashboard integrated with your code repository and deployment tools. Find something that gives you full visibility on branches, builds, pull requests, and deployment warnings in one place.

Automated deployment

Bitbucket logo Zephyr logo

There’s no magic recipe for automated deployment that will work for every application and IT environment. But converting operations’ runbook into a cmd-executable script using Ruby or bash is a common way to start. Good engineering practices are vital. Use variables to factor out host names – maintaining unique scripts or code for each environment is no fun (and misses half the point anyway). Create utility methods or scripts to avoid duplicated code. And peer review your scripts to sanity-check them.

Try automating deployments to your lowest-level environment first, where you’ll be using that automation most frequently, then replicate that all the way up to production. If nothing else, this exercise highlights the differences between your environments and generates a list of tasks for standardizing them. As a bonus, standardizing deploys through automation reduces “server drift” within and between environments.

Funzionamento


Logo di Appdynamics Logo di Datadog Logo di Slack Logo di SplunkLogo di New Relic Logo di Opsgenie Logo di Pingdom Logo di Nagios Logo di Dynatrace Logo di Hosted Graphite Logo di Sumo Logic

Monitoraggio delle prestazioni di applicazioni e server

Esistono due tipi di monitoraggio che è utile automatizzare: monitoraggio dei server e monitoraggio delle prestazioni delle applicazioni.

Selezionare manualmente una casella o testare l'API con un test è una scelta che va bene per il controllo a campione, ma per comprendere le tendenze e lo stato generale delle applicazioni (e degli ambienti), è necessario un software che ascolti e registri i dati 24 ore su 24, 7 giorni su 7. L'osservabilità continua è una funzionalità chiave per i team DevOps di successo.

Cerca gli strumenti che si integrano con il tuo client della chat di gruppo affinché gli avvisi arrivino direttamente nella stanza del tuo team o in una stanza dedicata agli imprevisti.

Logo di Jira Service Management Logo di Jira SoftwareLogo di Opsgenie logo di statuspage

Monitoraggio di imprevisti, modifiche e problemi

L'aspetto essenziale per ottimizzare la collaborazione tra i team DevOps è assicurarsi che visualizzino lo stesso lavoro. Cosa succede quando vengono segnalati imprevisti? Sono collegati e riconducibili a problemi software? Le modifiche apportate sono collegate a rilasci?

Nulla ostacola di più la collaborazione del personale di sviluppo con quello operativo che tenere traccia di imprevisti e progetti di sviluppo software in diversi sistemi. Cerca strumenti che ti consentano di riunire imprevisti, modifiche, problemi e progetti software su un'unica piattaforma, in modo da accelerare l'identificazione e la correzione dei problemi.

Observe


Application and server performance monitoring

AppDynamics logo DataDog logo Slack logo Splunk logoNew Relic logo Opsgenie logo Pingdom logo Nagios logo Dynatrace logo Hosted Graphite logo Sumo Logic logo

There are two types of monitoring that should be automated: server monitoring and application performance monitoring.

Manually “topping” a box or hitting your API with a test is fine for spot-checking. But to understand trends and the overall health of your application (and environments), you need software that is listening and recording data 24/7. Ongoing observability is a key capability for successful DevOps teams.

Look for tools that integrate with your group chat client so alerts go straight to your team’s room, or a dedicated room for incidents.

Feedback continuo


Logo di GetFeedback Logo di Slack Logo di Jira Service Management Logo di Pondo

Per capire se hai fatto la cosa giusta, devi solo ascoltare i clienti. Il feedback continuo include sia la cultura e i processi messi in atto per raccogliere feedback regolarmente, sia gli strumenti per acquisire informazioni dettagliate dal feedback. Le pratiche di feedback continuo includono la raccolta e la revisione dei dati NPS, sondaggi sul tasso di abbandono, segnalazioni di bug, ticket di assistenza e persino tweet. In una cultura DevOps, tutti i membri del team di prodotto possono accedere ai commenti degli utenti perché offrono indicazioni utili per tutte le attività, dalla pianificazione del rilascio alle sessioni di test esplorativi.

Cerca applicazioni che integrino il tuo strumento di chat con la tua piattaforma di sondaggi preferita per un feedback in stile NPS. Twitter e/o Facebook possono anche essere integrati con la chat per un feedback in tempo reale. Per un'analisi più approfondita sul feedback proveniente dai social media, è opportuno investire in una piattaforma di gestione dei social media in grado di estrarre report utilizzando dati storici.

L'analisi e l'integrazione del feedback potrebbero apparire attività che rallentano il ritmo di sviluppo a breve termine, ma nel lungo periodo offrono un'efficienza maggiore rispetto al rilascio di nuove funzioni che nessuno desidera.

In conclusione...


In Atlassian, crediamo nell'importanza di disporre di una toolchain DevOps che si integri con gli strumenti preferiti dai team di sviluppo e operativi. Ecco perché la nostra piattaforma DevOps è stata creata per integrarsi con oltre 171 importanti fornitori di terze parti leader, consentendoti di prendere le decisioni migliori sugli strumenti che utilizzi. Perché DevOps non dovrebbe essere acquistato da un singolo fornitore, ma creato.

Per iniziare, prova gratuitamente la soluzione DevOps di Atlassian.


Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Percorso di apprendimento DevOps

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up