Page break per la stampa in PDF con Confluence

Per aiutare la esportazione in PDF

In questo post andiamo ad analizzare un addon che ci permette di poter migliorare l’esportazione e stampa in PDF.

Di cosa si tratta

Nel dettaglio di tratta di sfruttare le User Macro, per le istanze server, in cui possiamo definire delle funzioni che non sono presenti su Confluence per poterci aiutare. In particolare possiamo definire ina interruzione id pagina in maniera molto semplice:

ovvero andiamo a definire una interruzione di pagina andando ad inserire un tag HTML direttamente sulla pagina attraverso questa macro.

Conclusioni

Abbiamo un piccolo barbatrucco che ci può aiutare nella redazione della nostra documentazione.

Reference

Maggiori informazioni sono reperibili in questa pagina dedicata della documentazione Atlassian.




EasyBI – Test addon

EasyBI – proviamolo

In questo post andremo ad testare questo addon particolarmente interessante. Approfitto per segnalare che a fine maggio si terranno gli EazyBI Days, dove saranno presentate le ultime novità di questo prodotto :-). Ho avuto il piacere di confrontarmi con loro durante il Summit Atlassian di Barcellona, di inizio maggio, ed è stata una occasione unica per confrontarsi e capire che cosa sia possibile fare con questi strumenti meravigliosi.

Installazione

Partiamo come sempre dalla installazione. In questo caso ci concentriamo sulla installazione per la versione Cloud che, come già sappiamo, presenta delle piccole differenze, ma non è affatto difficile da eseguire.

 

 

Configurazione

Proseguiamo la nostra esplorazione andando a vedere la configurazione dell’addon. Iniziamo dicendo che l’addon mette a disposizione una sezione dedicata che permette di configurare e definire tutto ciò che serve per le nostre analisi dei dati.

(questo ovviamente è l’esempio del mio account 🙂 )

Da li abbiamo le opzioni per poter:

  • Definire le nostre sorgenti dati (Source Data)
  • Impostare le nostre query (Analyze)
  • Creare le nostre Dashboard, per condividere le informazioni 🙂

Andiamo ad esaminare ogni singola opzione 🙂

Possiamo definire tutte le sorgenti dati, a partire dai nostri progetti JIRA, come possiamo vedere dalla immagine precedente, alle sorgenti dati vere e proprie come database.

Vediamo, come mostrato in figura, che la versione cloud permette di connettersi a diverse fonti, tra le quali anche database. Se lo scegliamo, possiamo scegliere le seguenti fonti:

Questo non è affatto male 😉

Una volta definite le fonti dati, possiamo creare le nostre interrogazioni, il tutto in maniera totalmente visuale 🙂

Da questo punto in avanti andiamo a testare il tutto 🙂

Test

Una volta definite le nostre interrogazioni, possiamo usarle sia nella dashboard di JIRA, da dove possiamo visionare direttamente i nostri dati, come possiamo vedere facilmente.

Una delle possibilità offerte da questi prodotti è quella di pubblicare questi report anche su Confluence, in maniera abbastanza semplice e diretta. Utilizzando un apposito Addon per l’ambiente cloud, è possibile arrivare a pubblicare i report nelle pagine.

L’aggiunta viene eseguita in maniera semplicissima, come mostrato in figura:

Aggiungendo l’addon Dashboard o Report, ed impostando quale report andare a visualizzare:

otteniamo il risultato atteso. Nel nostro caso, abbiamo installato l’addon (in maniera simile a quanto descritto in precedenza) ed il risultato è stato il seguente:

Quindi con pochissimo sforzo abbiamo pubblicato le nostre statistiche direttamente su Confluence molto semplicemente.

Conclusioni

Statistiche, dati, BI tutto all’interno di JIRA e dei prodotti Atlassian. Questo addon è una sorpresa dietro l’altra. bbiamo a disposizione tutto ciò che ci serve per poter arrivare a gestire i nostri dati direttamente dove serve.

Reference

Maggiori dettagli sono reperibili alla pagina del marketplace.




Come vediamo la definizione dei campi custom in JIRA Cloud o Server?

Piccolo barbatrucco

In questo post andiamo ad analizzare un piccolo trucco per vedere la definizione dei campi sotto JIRA Cloud.

Di cosa si tratta

Vi sarà capitato sicuramente, lavorando con un addon, viene restituito un messaggio di errore del tipo:

customfield_10006": "XXXXXXXXXX is required.

e non abbiamo la più pallida idea di come identificarli. Infatti, se andiamo nella definizione dei campi non abbiamo notizie del customfield_10006Tips direttamente dalla documentazione Atlassian. Come possiamo fare ad identificarli? Semplice. Ci viene in aiuto questo .

Per identificare i campi custom e non, identificando anche l’ID, possiamo semplicemente andare a richiamare:

https://<Your-JIRA-URL>/rest/api/2/field

ed il risultato è semplicemente questo:

ovvero un test che ho eseguito in una istallazione server locale, che utilizzo per mio test. Se lo eseguo su di una installazione cloud …. il risultato è il medesimo e abbiamo a disposizione tutti i campi, compresi i custom, come mostrato in figura:

 




JIRA Service Desk – Come collaborare al meglio

Un approfondimento

In questo post andremo ad approfondire alcuni aspetti di collaborazione tra utenti, agenti di JIRA Service Desk e sviluppatori.

Un piccolo recap….

In precedenti post abbiamo visto come si è evoluto JIRA Service Desk, che adesso andiamo a riassumere:

  • Agenti, che si occupano di gestire le richieste
  • Utenti, che si occupano di creare le richieste
  • Partecipant, ovvero un utente o un agente o un utente JIRA di altri progetti (lo sviluppatore o altro ruolo)

Questo ultimo è la nostra arma segreta, perchè ci permette di aggiungere persone alla segnalazione, in modo da consentirgli di poter leggere la segnalazione e di consentirgli di partecipare attivamente alla segnalazione.

Tenete sempre presente che tutti i prodotti della Atlassian si basano sempre sulla collaboration ed in questo articolo andremo a vedere come un Agente può richiedere l’aiuto di più soggetti per arrivare a risolvere la segnalazione dell’utente

Un caso di uso

Proseguiamo nella nostra esplorazione, analizzando e spiegando meglio questa situazione.

L’agente, quando riceve una segnalazione, può chiedere il supporto di uno sviluppatore o di un altro utente JIRA e una prima operazione che può eseguire è quella di inserire un nuovo partecipant, ovvero coinvolgere un utente nella risoluzione chiedendo delle informazioni particolari. Questo si può realizzare semplicemente con un click, direttamente dal task jira, quando si entra nel dettaglio della segnalazione.

Oppure possiamo anche inserire direttamente un commento interno, in cui andiamo a referenziare un utente, nel nostro caso potrebbe essere uno sviluppatore, cui chiediamo un supplemento di spiegazioni. le mentions ci aiutano tantissimo 😀

Un’altra possibilità è quella di aprire una segnalazione direttamente al progetto di manutenzione/sviluppo utilizzando l’apposita funzione, che permette di creare una issue collegata alla nostra di Service Desk..

In questo modo lo sviluppatore dispone già della segnalazione originaria, da cui ricava tutto ciò che gli serve, e può già lavorare alla risoluzione della stessa.

Conclusioni

Vediamo come nei prodotti Atlassian la collaborazione è sempre al centro di tutto. Non averemo mai persone sole contro gli utenti cattivi, ma delle squadre, dei team che si occupano di gestire le situazioni.

Reference

Maggiori informazioni sono presenti nel seguente articolo su JIRA Service Desk, da cui ho preso spunto per costruire questo articolo.

 




Bulk edit in JIRA – Modifiche multiple

Un pò di manualistica

In questo post andremo a vedere un pò di manualistica, che non fa mai male. In questo caso andiamo a spulciare nella manualista per capire come possiamo eseguire una BULK edit in JIRA 🙂

In cosa consiste

JIRA permette di eseguire una operazione di modifica/editazione multipla (Bulk edit appunto) delle issues. Questa operazione è sicuramente ottima quando si deve eseguire delle operazione che impatta più issue.  Se le dovessimo eseguire singolarmente…. aiuto

Ma prima di tutto

occorre sapere che questa opzione deve essere attivata. Andare quindi nelle permissions del progetto e … attivarle. L’attivazione è comandata dalle Global Permission (le trovate sotto le pagine di amministrazione, sezione System).  Da li andiamo a trovare la nostra bella opzione e…. forniamo le grant necessarie per poter avere  l’opzione disponibile.

Dalla figura vediamo come possiamo settare chi può usufruire della funzionalità.

Una volta configurata?

Possiamo fare tante bellissime cose 🙂

che adesso andiamo ad esaminare in dettaglio:

  • Eseguire una transazione per un insieme di issues
  • Cancellazione, modifica e spostamento di un insieme di issues
  • Modificare il Watch di issues

Operazioni che, se eseguite una per volta, ci fanno invecchiare istantaneamente.

Come usiamo il tutto?

Bellissima domanda. Prima dobbiamo cercare il nostro insieme di issues da … trattare. Quindi andiamo ad applicare l’opzione che vogliamo :-), come mostrato nella seguente figura.

 

Una volta selezionata, passiamo al wizard che ci guiderà nella operazione che vogliamo fare. La prima operazione del wizard, come mostrato dalla seguente figura:

scegliamo quali issues andiamo a trattare. Il secondo passo è il seguente:

scegliamo l’operazione da eseguire. Supponendo di selezionare Edit Issues , viene proposta una nuova form che richiede quali modifiche operare :-), come mostrato della seguente figura.

Una volta inserite le informazioni necessarie, confermiamo e operiamo le modifiche.

Conclusioni

Abbiamo visto un esempio di come poterci semplificare la vita grazie alle funzionalità di JIRA. Continueremo sempre a pubblicare articoli didattici e di aiuto per gli utenti.

Reference

Per qualsiasi altre informazioni, in inglese, fate riferimento alla pagina del manuale.

 




Agile Board cross-progetti – Come la realizziamo? Che cosa possiamo fare?

Una breve divagazione

In questo post facciamo una breve divagazione sulle Agile Board. Cerchiamo di capire come possiamo sfruttare questo strumento  in vari ambiti e, sopratutto, vediamo come possiamo adattare alle nostre esigenze lo strumento.

Ringraziamenti

Un ringraziamento a Maria Luisa, per il lavoro che sta svolgendo con i prodotti Atlassian e che ha causato questa divagazione. 🙂

Vediamo come possiamo ….

… sfruttare la Agile Board a nostro uso e consumo. Infatti, si presta bene a diversi utilizzi, come ho già avuto modo di mostrare nel Workflow che ho già pubblicato qui nel marketplace della Atlassian, dove ho mostrato come poter utilizzare la Agile Board per tracciare il flusso delle fatture.

Un altro esempio lo trovate anche in questo post, che ho dedicato ad una ipotesi di realizzazione di Asset Management, dove anche li ho mostrato come la Agile Board trova un suo utilizzo molto naturale nel tracciare lo stato di ogni singolo asset.

TAG06

Di conseguenza ….

… forti di queste esperienze, possiamo anche ipotizzare che ci siano anche altri possibili utilizzi delle board, anche non proprio relative alla metodologia Agile.

Stato di fatto – Fotografia – Snapshot

Un utilizzo che possiamo avere della Agile Board è quello di tracciare in generale lo stato di fatto. Allo stesso modo usato negli altri esempi. Un altro esempio riguarda il post che ho dedicato alla recensione dell’addon del Kanoah CRM, dove gli autori dell’addon hanno praticamente utilizzato una board per tracciare l’andamento degli affari.

Altri utilizzi?

Lasciamo che sia la nostra fantasia a trovare altri usi :-). Possiamo anche ipotizzare che sia gestita anche per gestire i percorsi di carriera del personale di una azienda. In questo caso, le issue sono utilzzate per rappresentare il dipendente, con tutte le sue informazioni, mentre gli stati del workflow sono i gradi di avanzamento di carriera/assegnazione incarichi e chi più ne ha ne metta, sfruttando anche la potenzialità di Confluence 🙂

Un altro esempio potrebbe essere la gestione di un parco macchine di una azienda. Le issue possono essere utilizzate per rappresentare le automobili, mentre gli utenti di JIRA sono il personale che ottiene in gestione l’auto…. ma questo è solo un possibile applicazione di un utilizzo un pò più generico: ovvero gestire la assegnazione di risorse e, utilizzando anche un altro addon che abbiamo censito, per rintracciarlo a livello geografico.

Ma la board è legata ad un solo progetto?

Fondamentalmente le Board sono legate ad un progetto, anche se possiamo sfruttarle per andare a leggere le informazioni anche da issue appartenenti a diversi progetti. Occorre però tenere presente alcune piccole accortezze per arrivare a gestirle al meglio.

  1. Possiamo selezionare le issues che vogliamo, basta semplicemente impostare la JQL di cui si vuole
  2. Occorre prestare attenzione: se il filtro JQL non presenta il campo project , allora la Board potrebbe non risultare associata al progetto o fruibile dalla Dashboard del progetto, come mostrato nella immagine successiva
  3. Se vogliamo sfruttare le potenzialità della board di modificare lo stato delle issue, accertiamoci che le issue dei progetti selezionati presentino lo stesso workflow, che presentino gli stessi stati e che la Board sia configurata in maniera tale da telere conto degli stessi stati, ovvero quali stati e quale colonna etc. Se presentano WF differenti, potremmo non avere il comportamento che ci aspettiamo 🙂

Conclusioni

Abbiamo fatto una semplice digressione sull’argomento. Questo è sicuramente uno punto di partenza per altri ragionamenti che porterà sicuramente a conclusioni interessanti.

 




knowledge base su JIRA Service Desk

Creiamo una Knowledge Base con JIRA Service Desk

In questo post andremo ad esaminare un sistema per poter gestire la Knowledge base su JIRA Service Desk, ovvero mettere a disposizione dei nostri clienti una libreria in cui sono specificate tutte le risoluzione alle varie problematiche, permettendo di poter risolverle in autonomia.

Di cosa abbiamo bisogno?

Come prima cosa dobbiamo disporre di Confluence nella nostra installazione, come mostrato anche dalla seguente figura:

 

Per realizzare questa funzionalità, JIRA Service Desk si appoggia ad uno Space di Confluence, dove si costruiscono, attraverso opportune procedure, le pagine della KB. Se Confluence non è disponibile o non è stato opportunamente collegato con il sistema, questa è la schermata che JIRA Service Desk visualizza per avvisare della situazione:

Impostando l’opzione Link to a Confluence space, la prima cosa che si nota è la presenta su portal della barra di ricerca, come mostrato in figura.

Questa è la barra di ricerca che l’utente utilizza per procurarsi la eventuale risoluzione del problema che ha riscontrato.

Come avviene la generazione?

Per generare le varie KB, ABbiamo a disposizione una apposita funzionalità, presente nella default view della issue, come mostrato in figura:

Gli agenti possono quindi, se non ci sono articoli già presenti e se si tratta di problematiche che si possono ripresentare, creare i KB per consentire agli utenti di cercarsi le soluzioni. Abbiamo solo da scegliere il template da usare per creare l’articolo su Confluence 🙂

Conclusioni

Abbiamo visto un semplice tutorial che ci mette a disposizione una buona funzionalità per JIRA Service Desk.

Reference

Suggerisco anche il seguente articolo del blog ufficiale Atlassian, dove sono fornite ulteriori informazioni.




Dalla pagina bianca alla documentazione

Una nuova esplorazione

Con questo post iniziamo una nuova esplorazione nel mondo dei Wiki. Affrontiamo uno dei problemi maggiori nel campo: Come andiamo a redigere una documentazione che abbia un senso e che permetta, un domani, di essere  condivisibile e permetta agli utenti di avere a disposizione un percorso di lettura valido, sensato e coerente.

Da cosa partire

Avere le idee chiare

La prima cosa che occorre fare è sicuramente cercare di classificare tutte le informazioni e gli utenti che andranno a referenziarle. In questo modo abbiamo riusciamo ad avere una prima indicazione di come classificare le informazioni, in quali SPACE andare a inserirle, se abbiamo bisogno di collegare delle informazioni, etc etc etc

Questo ovviamente è solo l’inizio. Occorre studiare bene questa prima parte, per un motivo molto semplice: Inserire delle informazioni a caso su di un Wiki non ha praticamente senso. Faccio un esempio molto semplice: Se si inseriscono delle pagine a caso e queste non sono collegate tra di loro (aggiungo anche: collegate in maniera opportuna, ma nella maniera più improbabile), questo significa che abbiamo solo un caos semi-disorganizzato, che non ci aiuta minimamente nel reperire le info. Passeremo le nostre giornate a ricercare le informazioni. Lo strumento non ci aiuterà in nessun modo 🙁 e la prima reazione sarà quella di copiare le informazioni in locale sul nostro PC/tablet.

Fate sempre ordine

Occorre studiare come inserire le informazioni e come organizzarle, classificarle, collegarle. Questo ultimo punto è sicuramente il più importante in quanto anche delle belle pagine chiare e illuminanti non hanno alcun senso se non sono collegate tra di loro. Occorre mettersi in testa che l’utente non deve fare la caccia al tesoro per reperire le informazioni.

Non seguire le mode…

Molto spesso si commette l’errore che basti introdurre lo strumento in azienda o semplicemente adottarlo per risolvere tutti i problemi di documentazione, come avevo già indicato in questo post, in cui ho riportato una prima serie di considerazioni sulla documentazione su Wiki.

Se le informazioni sono collegate in maniera tale da creare dei percorsi di lettura, quello che si ottiene è una documentazione valida.

Obbiettivo di questi post

Con questa nuova serie di post, ci prefiggiamo l’obbiettivo di fornire una serie di consigli per gli utenti, inteso più come un nuovo modo di ragionare e di organizzare le informazioni che porti gli utenti ad avere a disposizione una documentazione il più possibile fruibile ed utile.

Non intendo fornire tanto delle norme rigide ed immodificabili, ma quanto una serie di consigli e di punti di attenzione che possono aiutare nella redazione della documentazione e nell’organizzazione della stessa. La vera potenzialità dei prodotti Atlassian risiede proprio nel grado di libertà che si ha a disposizione 🙂

In conclusione

Chiudiamo qui questo post introduttivo. Abbiamo ripreso quanto avevo già indicato in altri post e cerchiamo di esploderlo nei prossimi post con esempi pratici, modalità di ragionamento e, importantissimo, uso corretto della testa 🙂




Anomalia sulla procedura di caricamento di Workflow

Anomalia sulla procedura di caricamento Workflow

In questo post segnaliamo una anomalia che si potrebbe presentare in fase di caricamento di un Workflow, come indicato nella procedura Importing from local instance, e per alcune versioni datate di JIRA CORE, potrebbe essere un attimo …. fastidioso.

Ringraziamento

Rigrazio Francesco Borchetta per la segnalazione.

Nel dettaglio

Questa anomalia si presenta fino alla versione 7.1.7 server. Quando si esegue l’importazione di un Workflow, seguendo la procedura da manuale, rischiamo di non riuscire. Se andiamo a verificare il log, questo è il risultato:

24-May-2016 18:14:56.057 WARNING [http-nio-8717-exec-25] org.apache.catalina.connector.Response.sendRedirect Failed to redirect to [summary?atl_token=BC5X-3E6C-B9U6-B82F|e6b3dc7ef6ba6448e3e3e5827fa223dfe7952a0f|lin]
 java.lang.IllegalArgumentException: Illegal character in query at index 37: summary?atl_token=BC5X-3E6C-B9U6-B82F|e6b3dc7ef6ba6448e3e3e5827fa223dfe7952a0f|lin
	at java.net.URI.create(URI.java:852)
	at org.apache.catalina.connector.Response.sendRedirect(Response.java:1280)
	at org.apache.catalina.connector.Response.sendRedirect(Response.java:1252)
	at org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:500)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
	at com.atlassian.gzipfilter.SelectingResponseWrapper.sendRedirect(SelectingResponseWrapper.java:93)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
	at com.opensymphony.module.sitemesh.filter.PageResponseWrapper.sendRedirect(PageResponseWrapper.java:212)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
	at javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpSer

Workaround

Per fortuna, abbiamo a disposizione una workaround, disponibile nella stessa segnalazione della anomalia, che ci permete di poter risolvere il problema:

Workaround

  1. Procedere con la normale procedura di importazione di un Workflow
  2. Una volta raggiunto la URL http://<Base URL>/plugins/servlet/wfshare-import/map-statuses, seleziona tutti gli stati e quindi dare un click su Next (a questo punto siamo rediretti ad una pagina bianca, e l’errore è stato geenrato )
  3. Aprire l’ultimo stderr logs (Windows) o catalina.out logs (Linux) della propria istanza (localizzata su <JIRA Install>/logs directory) e cercare il seguente errore:
  4. 31-May-2016 18:14:49.109 WARNING [http-nio-7171-exec-17] org.apache.catalina.connector.Response.sendRedirect Failed to redirect to [summary?atl_token=B0KP-OKMI-GE40-K8NA|7412a2a4cd5c29b28d9247a0a93dbc9056c6a85b|lin]
     java.lang.IllegalArgumentException: Illegal character in query at index 37: summary?atl_token=B0KP-OKMI-GE40-K8NA|7412a2a4cd5c29b28d9247a0a93dbc9056c6a85b|lin
    	at java.net.URI.create(URI.java:852)
    	...
    Caused by: java.net.URISyntaxException: Illegal character in query at index 37: summary?atl_token=B0KP-OKMI-GE40-K8NA|7412a2a4cd5c29b28d9247a0a93dbc9056c6a85b|lin
    	at java.net.URI$Parser.fail(URI.java:2848)
    	...
    
  5. Copia la stringa da summary in avanti. Riprendendo l’esempio del punto precedente, copia summary?atl_token=B0KP-OKMI-GE40-K8NA|7412a2a4cd5c29b28d9247a0a93dbc9056c6a85b|lin
  6. Attacca questa stringa alla fine della URL che viene proposta quando vien evisualizzata la pagina bianca (ad esempio: http://<Base URL>/plugins/servlet/wfshare-import/map-statuses). La URL finale dovrebbe risultare:
    http://<Base URL>/plugins/servlet/wfshare-import/map-statuses/summary?atl_token=B0KP-OKMI-GE40-K8NA|7412a2a4cd5c29b28d9247a0a93dbc9056c6a85b|lin
  7. Incolla questa nuova URL nel browser e procedi. Questo dovrebbe far arrivare al passo siccessivo.

Conclusioni

Abbiamo questa Workaround disponibile per gestire l’errore, qualora abbiamo a disposizione una versione soggetta al problema e, per varie ragioni, non possiamo eseguire un aggiornamento di versione.




Bitbucket – Proseguiamo la nostra esplorazione

Il viaggio continua

In questo post proseguiamo quanto iniziato dai seguenti post, dedicati a Bitbucket, ovvero:

Proseguiamo….

In questo post andremo ad esaminare le operazioni che sono possibili su BitBucket, che cosa possiamo fare, come possiamo usarlo una volta installato/disponiamo l’accesso.

…. parlando di GIT e BitBucket

Iniziamo l’esplorazione calando i concetti di GIT in BitBucket, e ci facciamo aiutare dai tutorial che la stessa Atlassian mette a disposizione :-), in modo da avere sempre dei validi punti di riferimento.

La prima cosa che andimo a vedere è il concetto di Repository, che non si discosta molto dal concetto di che già usiamo nei progetti di SVN o similari. In soldoni, è il punto dove andiamo a memorizzare i nostri progetti e, di conseguenza, in nostri file. La seguente immagine ci descrive molto bene quello che bitbucket ci mette a disposizione come repository.

Una volta che il repository è creato nel nostro BitBucket, possiamo caricare i file al suo interno. In aggiunta, possiamo anche far importare i nostri progetti direttamente da altri sistemi di controllo versione, senza alcuna difficoltà. Da questo momento sarà lui il nostro repository centrale dove andremo ad eseguire tutte le operazioni di merge

 

Ed una volta caricati i dati?

Una volta che i dati sono stati caricati, possiamo iniziare a lavorare eseguendo delle operazioni di Clone, ovvero per scaricare i dati sul nostro respository GIT locale e da li…. procedere con i nostri sviluppi. Occorre sempre tenere presente che, nei repository GIT locali, noi abbiamo sempre una copia completa di tutto.

Al termine dei nostri sviluppi, una volta che tutto è pronto, inizia la fase più delicata: il Merge. In questa fase andiamo a riportare le modifiche eseguite nel repository locale, sul repository master.

Questa fase è sempre molto delicata e deve essere sempre eseguita con cura, ma in questo BitBucket ci mette a disposizione diversi strumenti per aiutarci. Di conseguenza possiamo stare molto tranquilli.

Conclusioni

Fermiamo qui questa esplorazione. Nei prossimi post andremo a visionare diverse situazioni e cercheremo di analizzare nel dettaglio le varie funzionalità.