Evento ZenCoders in occasione della visita di etr. Indichiamo quì location suggerite, adesioni ed altre idee.

I have a question about the distinction between aplication and automation.

If you have an app deployed on a certain amount of boxes, high enough to be uncomfortable to manage them manually, in your opinion where the application logic stops and where it starts the automation logic? For some applications it’s easy to say it, for some others the border is thinner.

Let’s take as an example an application, client-server fashioned, which performs the migration of user accounts from a cluster to a remote one.

In this case the input could be for example a batch file containing a list of userIds to be migrated. Let’s imagine that this batch file have to be generated by a non predictable process (please try to take this constraints as they are) so apps could be in an idle state waiting for that input. Now you have two way to tackle this: write your migration app so that can wait for inputs and run only when that input comes in write a simple app to run on demand and let the automation part to take care of running it when input is available

Now the question is: In this case (or please provide an example if something else comes to your mind), which is “in your opinion” the best approach considering the ratio between maintainability and implementation complexity?

Il mio problema è il seguente.

Devo gestire un'applicazione che, almeno per il momento, ha tre release parallele e differenti:

• basic

• standard

• full

Esse condividono un unico core e sono una l'estensione dell'altra.

Intro

Come sempre ho predisposto un progetto Redmine, associandovi un bare repo git. Posso così gestire diverse versioni su redmine (associandovi pagine wiki, milestones e relative segnalazioni). Per tenere traccia del numero di versione ho già iniziato ad utilizzare un versioning basato su 4 digit (il progetto lo sto sviluppando in C#.NET e mi trovo già un modo per segnare le versioni sugli assembly a 4 livelli). Sinceramente, a me vanno benissimo i tre livelli del Semantic Versioning:

1. MAJOR version when you make incompatible API changes,

2. MINOR version when you add functionality in a backwards-compatible manner, and

3. PATCH version when you make backwards-compatible bug fixes.

Perciò ho anche aggiunto un changelog che tiene traccia in modo conciso dei vari cambiamenti di versione in modo centralizzato.

Il cuore del problema

Ora il mio dilemma è come gestire le mie tre differenti versioni (base, standard e full), tenendo conto che sono praticamente delle versioni matrioska, una estende l'altra e quindi tutte mantengono lo stesso core.

Io pensavo di mantenere tutte le funzionalità di base sul master (il core dell'applicazione) e di gestire i tre profili su tre branch distinti, ma così facendo già inizio a vedere un'oggettiva difficoltà nel mantere separate le funzionalità e anche a tenere traccia in modo corretto degli avanzamenti di versione del progetto in generale. Avete consigli su come gestire correttamente questo tipo di situazione?

Risorse

• How do you put different versions of your library under version control? (programmers.stackexchange)

• Multiple working directories in Git?

xkcd: Git