Déploiement et contrôle de version d'applications

Article
08/18/2010

Notes

Les informations suivantes sont fournies à titre de référence pour les applications existantes qui ne prennent en charge que les scénarios hors connexion. Pour le développement de nouvelles applications, consultez Architecture et classes pour la synchronisation de base de données.

Cette rubrique décrit le déploiement et le contrôle de version des applications clientes et serveur. Pour plus d'informations sur l'initialisation des bases de données d'homologues, consultez « Initialisation d'une base de données serveur » dans Procédure : configurer et exécuter la synchronisation collaborative (non-SQL Server).

La méthode que vous adoptez pour le déploiement d'une application cliente et serveur utilisant Sync Framework varie selon qu'il s'agit d'une application à deux couches ou multicouche. Dans une application à deux couches, tout le code de synchronisation est situé sur le client, et l'application peut être déployée comme n'importe quelle application reposant sur SQL Server Compact. En règle générale, le déploiement implique soit l'utilisation de ClickOnce pour publier l'application, soit l'empaquetage de l'application puis sa copie sur chaque client. Pour plus d'informations sur le mode de déploiement des applications qui utilisent SQL Server Compact, consultez les rubriques « Déploiement d'applications » et « Procédure : créer et déployer une application sur un ordinateur de bureau » dans la documentation en ligne de SQL Server Compact. Dans une application multicouche, vous devez également déployer le code sur l'ordinateur qui héberge les composants de synchronisation côté serveur.

Création et initialisation de la base de données client

Pour les applications à deux couches et multicouches, vous devez déterminer la méthode de création et d'initialisation de la base de données client qui contient le schéma et les données nécessaires à l'application. Il existe deux approches principales :

Utilisez Sync Framework pour créer la base de données et téléchargez les données et le schéma de la table lors de la première synchronisation. Il s'agit de l'approche la plus simple. Toutefois, elle peut impliquer un trafic réseau et un traitement serveur importants si vos clients sont nombreux et vos données volumineuses.
Pré-créez la base de données qui contient le schéma de table et un groupe de données initial. La base de données, au format de fichier .sdf, peut être transportée ou téléchargée par l'application cliente. Si l'application télécharge des modifications incrémentielles, elle peut mettre à jour la base de données client au cours de la première synchronisation. Si vous utilisez cette approche, définissez une valeur appropriée pour la propriété CreationOption.

Si l'application inclut des téléchargements ascendants et que vous voulez savoir d'où proviennent les modifications, l'application peut définir la propriété ClientId de sorte qu'elle identifie de manière unique la base de données client auprès du serveur ; ou Sync Framework génèrera un nouvel ID pour la base de données.

Notes

La pré-création de la base de données client n'est pas appropriée pour les applications dans lesquelles les données sont filtrées de manière différente pour chaque client. Elle peut entraîner l'omission de modifications durant la synchronisation initiale.

Pour plus d'informations sur le mode d'initialisation de la base de données client, consultez Procédure : initialiser la base de données client et travailler avec un schéma de table.

Contrôle de version d'applications

Une fois qu'une application a été développée et déployée, il est possible que de nouvelles versions de cette application soient développées. Deux critères doivent être pris en compte pour le contrôle de version d'application :

Les parties de l'application qui sont affectées par une nouvelle version
La nécessité, ou non, qu'une nouvelle version coexiste avec les versions antérieures

En règle générale, une application multicouche est plus facile à mettre à jour pour Sync Framework, car vous pouvez mettre à jour les composants côté serveur indépendamment des composants côté client. Vous pouvez ainsi exposer un nouveau service qui comprend des fonctionnalités mises à jour et les clients sont ainsi isolés des modifications côté serveur tant qu'ils ne sont pas prêts à procéder à la mise à jour des composants côté client.

Contrôle de version pour les applications multicouches

Pour Sync Framework, la principale mise à jour d'application à envisager est une modification de schéma de la base de données serveur. Sync Framework ne propage pas automatiquement les modifications de schéma du serveur au client. Il prend toutefois en charge les modifications de schéma dans la mesure où vous mettez à jour les parties appropriées de l'application. Pour obtenir la liste des modifications de schéma prises en charge dans la base de données client, consultez Utilisation des schémas de table dans la base de données client. Si une modification de schéma est opérée dans la base de données serveur, vous devez, en premier lieu, déterminer si cette modification doit être propagée au client. Par exemple, si vous ajoutez une colonne de carte de crédit à une table de la base de données serveur mais que vous disposez d'une règle métier qui interdit aux employés d'utiliser les informations de carte de crédit hors connexion, il n'est pas nécessaire de propager la modification de schéma au client. Si vous décidez de propager la modification de schéma, la méthode que vous utilisez dépend du type de modification.

Modifications de schéma courantes

Les deux modifications de schéma les plus courantes sont l'ajout d'une colonne à une table et l'ajout d'une nouvelle table, ou la décision d'inclure une table existante qui ne faisait pas partie de l'application au départ. Si l'application impose la synchronisation d'une nouvelle table, vous devez ajouter un objet SyncAdapter à la table. Une fois les composants serveur mis à jour, l'application cliente ou l'utilisateur de l'application peut déterminer si la nouvelle table doit être synchronisée. Si le choix se porte sur la synchronisation de la nouvelle table, les composants clients doivent être modifiés afin d'inclure un objet SyncTable pour la nouvelle table. Ces modifications doivent être transférées vers chaque application cliente d'une manière ou d'une autre. La technologie ClickOnce vous permet de publier des mises à jour d'application, et les applications peuvent vérifier, avant de démarrer, si des mises à jour sont disponibles. Si vous ajoutez une nouvelle colonne à une table et que vous optez pour la synchronisation de cette colonne, vous devez ajouter la colonne dans la base de données client et mettre à jour les commandes utilisées pour synchroniser les modifications. Pour les modifications de schéma qui ne consistent pas à ajouter une nouvelle colonne, supprimez la table sur le client et recréez-la à l'aide de Sync Framework ou d'un autre mécanisme.

Coexistence des versions

Dans certains scénarios, la nouvelle version et l'ancienne version d'une application cliente sont amenées à coexister. Dans ce cas, vous pouvez utiliser deux approches :

Vous pouvez conserver plusieurs versions des composants serveur afin qu'une ancienne version des composants clients puisse continuer à accéder à la version appropriée des composants serveur. La meilleure approche du contrôle de version consiste à exposer un nouveau service avec des fonctionnalités mises à jour. Les clients peuvent être mis à niveau en utilisant la technologie ClickOnce. Une fois la mise à niveau terminée, le client est redirigé vers le nouveau service Web.

Vous pouvez concevoir les composants client et serveur de sorte qu'ils utilisent un paramètre de version d'application. Cette approche permet à l'application cliente d'indiquer au serveur quelle version est attendue. Examinons l'exemple suivant où la procédure stockée qui sélectionne les insertions à partir du serveur accepte un paramètre @appversion. Un paramètre est ajouté à la propriété SelectIncrementalInsertsCommand, puis une valeur est fournie à l'aide d'un objet SyncParameter dans l'objet SyncAgent. Lors de la synchronisation, la version de l'application est envoyée au serveur et la procédure stockée sélectionne la version appropriée du schéma de table.

this.Configuration.SyncParameters.Add(
      new SyncParameter("@appversion", 1));
customerIncrUpdates.Parameters.Add("@appversion", SqlDbType.Int);

Me.Configuration.SyncParameters.Add( _
      New SyncParameter("@appversion", 1))
customerIncrUpdates.Parameters.Add("@appversion", SqlDbType.Int); 

CREATE PROCEDURE usp_CustomerSelectIncrementalInserts(
    @sync_last_received_anchor timestamp, 
    @sync_new_received_anchor timestamp, 
    @appversion int
)

AS
    IF @appversion = 1
    BEGIN
        SELECT CustomerId, CustomerName, SalesPerson
        FROM Sales.Customer 
        WHERE InsertTimestamp > @sync_last_received_anchor 
        AND InsertTimestamp <= @sync_new_received_anchor
    END
    ELSE IF @appversion = 2
    BEGIN
        SELECT CustomerId, CustomerName, SalesPerson, CustomerType
        FROM Sales.Customer 
        WHERE InsertTimestamp > @sync_last_received_anchor 
        AND InsertTimestamp <= @sync_new_received_anchor
    END
    ELSE
    BEGIN
        PRINT('Unrecognized version')
        RETURN
    END

Voir aussi

Autres ressources

Architecture et classes pour la synchronisation client et serveur

Considérations sur la conception et le déploiement d'applications

Partager via