Comment transférer des fichiers en production?

Nous sommes un groupe qui a commencé à travailler sur un site Web assez grand avec une base de code existante. Nous avons un test et un serveur de production.

Notre idée est d'avoir un référentiel de test avec un certain nombre de développeurs ayant un accès push à; et un dépôt béni que seuls quelques-uns peuvent pousser. Le dépôt béni est censé être toujours stable et représenter la dernière version de production.

Comment automatiser le processus de transfert des fichiers en production? Est-ce mauvais d'avoir les fichiers de production sous contrôle de version? De cette façon, pousser vers le dépôt béni signifierait un déploiement. Mais que se passe-t-il en cas de conflits de fusion? Le serveur de production se cassera-t-il jusqu'à ce qu'il soit résolu?

Pour faire simple:
le processus push en lui-même devrait être entièrement automatique. Que vous ayez un script personnalisé ou que vous passiez simplement du dépôt "béni" à l'environnement de production. Ça dépend de toi. Vous devriez simplement avoir quelque chose d'automatisé, car les processus automatisés peuvent être rendus fiables (par opposition au téléchargement de fichiers à la main et autres).

Cependant, le processus push doit être déclenché manuellement. Vous poussez vos mises à jour, et une fois que vous vous sentez confiant, vous le marquez comme une version candidate et le tirez vers votre environnement de test (qui serait idéalement aussi similaire à votre environnement de production que possible). Une fois le RC testé, la poussée peut être lancée.
À ce jour, rien d'autre ne peut vous donner ce que les testeurs humains peuvent faire.

Cela semble un peu lent, dans le sens où la boucle de rétroaction est relativement grande. Mais pour un test correct, il est important de prendre un instantané fixe, qui est ensuite examiné pendant 24 à 48 heures (ou peut-être plus, selon la taille du projet). Le contraire est un scénario, où vous trouvez beaucoup de bugs juste après avoir poussé et vous essayez de le corriger avec quelques correctifs rapides qui introduisent de nouveaux bugs.
Vous feriez mieux de faire une version avec des bogues connus (de gravité acceptable), qu'une version avec des bogues inconnus (de gravité inconnue).

J'ai beaucoup appris sur le déploiement en regardant comment Capistrano fonctionne. Je travaillais avec RoR à l'époque, c'était donc un choix logique et même si je ne l'ai jamais vraiment fait pour le projet sur lequel je travaillais, la façon dont il effectue les mises à jour automatisées a été très utile.

Vous pouvez être dans une situation où vous pouvez l'utiliser directement même - il n'est pas nécessairement lié à Rails - mais sinon, la façon dont il se comporte est certainement utile.

Selon la plate-forme que vous utilisez, il existe de nombreux outils qui pourraient vous être utiles pour automatiser les versions de production. Je travaille dans une boutique .NET, donc nous utilisons NAnt (bien que MSBuild soit une meilleure option de nos jours). Java a Ant et peut-être d'autres choses. Ruby a des choses comme Rake. Ensuite, il existe des plates-formes d'intégration continue comme TeamCity et Hudson qui peuvent également être utilisées pour gérer les versions.

Je n'ai jamais vu ni entendu parler d'avoir le code prod directement dans un référentiel de contrôle de source séparé, mais cela pourrait certainement fonctionner. Comme l'a dit back2dos, la clé est d'automatiser. Nous avons nos scripts de génération conçus pour extraire du contrôle de code source, créer et pousser vers un environnement intermédiaire pour les tests. Ensuite, lorsque nous aimons le fonctionnement de la mise en scène, les scripts sont copiés de QA vers Prod.

Ma recommandation est d'examiner les outils disponibles et d'en choisir un, puis de concevoir un processus qui fonctionnera bien avec l'outil sélectionné. N'essayez pas de réinventer trop la roue - c'est un problème très résolu.