Chaque fois qu'un nouveau développeur rejoint l'équipe ou l'ordinateur qu'il utilise, le développeur doit effectuer beaucoup de travail pour configurer l'environnement de développement local afin que le projet en cours fonctionne. En tant qu’équipe SCRUM, nous essayons d’automatiser tout, y compris le déploiement et les tests. Je vous pose donc la question suivante: existe-t-il un outil ou une pratique pour automatiser la configuration de l’environnement de développement local?
Par exemple, pour configurer mon environnement, je devais d'abord installer Eclipse, puis SVN, Apache, Tomcat, MySQL, PHP. Après cela, j'ai rempli la base de données et j'ai dû apporter des modifications mineures aux divers fichiers de configuration, etc. Existe-t-il un moyen de réduire ce travail en un seul clic?
Il existe plusieurs options, et parfois une combinaison de celles-ci est utile:
Détails sur les différentes options:
Installation automatisée Outils pour automatiser l'installation et la configuration des divers services, outils et fichiers de configuration d'un poste de travail:
Images disque Ensuite, bien sûr, il existe également des outils de création d'image disque pour stocker l'image d'un hôte configuré de manière à pouvoir la restaurer sur un autre hôte. Comme pour la virtualisation, cela est particulièrement intéressant pour les boîtiers d’essai, car il est facile de restaurer les choses dans l’ordre propre. Garder les choses constamment à jour est toujours un problème - vaut-il la peine de créer de nouvelles images simplement pour propager un changement de fichier de configuration?
La virtualisation est une autre option, par exemple, la copie d'une image Xen, VirtualPC ou VMWare pour créer de nouveaux hôtes. Ceci est particulièrement utile avec les boîtes de test, car peu importe le gâchis créé par un test, vous pouvez facilement restaurer l'état propre et connu. Comme pour les outils de création d'image de disque, maintenir les hôtes à jour nécessite davantage de procédures manuelles et de vigilance que si un outil d'installation/de configuration automatisé était utilisé.
Contrôle du code source Une fois que vous avez installé/configuré les outils nécessaires, vous devez ensuite générer les versions pour vérifier ce qui est nécessaire dans un référentiel de code source et le construire.
Actuellement, j'utilise une combinaison de ce qui précède pour automatiser le processus comme suit:
Je suis tombé sur cette question et j'ai été très surpris que personne n'ait encore mentionné Vagrant .
Comme Pete TerMaat et d’autres l’ont mentionné, la virtualisation est un excellent moyen de gérer et d’automatiser les environnements de développement. Vagrant élimine la douleur de la mise en place de ces boîtes virtuelles.
En quelques minutes, vous pouvez obtenir une copie entièrement fraîche de votre distribution Linux préférée et utiliser provisioned exactement de la même manière que votre serveur de production.
Plus besoin de se battre avec OSX ou Windows pour installer PHP, MySQL, etc. Tous les logiciels vivent et s'exécutent dans la machine virtuelle. Vous pouvez même entrer SSH avec vagrant ssh
. Si vous faites une erreur ou cassez quelque chose, mettez simplement vagrant destroy
et vagrant up
pour recommencer à zéro.
Vagrant crée automatiquement un dossier synced dans votre système de fichiers local, ce qui signifie que vous n'avez pas besoin de développer votre ordinateur virtuel (c.-à-d. À l'aide de Vim). Utilisez ce que votre éditeur de choix est.
Je crée maintenant une nouvelle "boîte à vagabond" pour presque chaque projet que je réalise. Tous mes paramètres sont enregistrés dans le référentiel du projet, il est donc facile de faire appel à un autre membre de l'équipe. Ils doivent simplement extraire le dépôt et exécuter vagrant up
, et ils sont littéralement prêts à partir.
Cela facilite également beaucoup le traitement des projets ayant des exigences logicielles différentes. Vous avez peut-être des projets qui reposent sur PHP 5.3, mais des projets plus récents exécutant PHP 5.4. Installez simplement la version de votre choix pour ce projet.
Un point important est de configurer vos projets dans le contrôle de source de sorte que vous puissiez immédiatement construire, déployer et exécuter après la vérification.
Cela signifie que vous devez également archiver l'infrastructure d'assistance, telle que les fichiers Makefiles, les fichiers de compilation, etc., ainsi que les paramètres des outils, tels que les fichiers de projet IDE.
Cela devrait prendre en charge la configuration difficile pour des projets individuels.
Pour la configuration de base de la machine, vous pouvez utiliser une image standard. Une autre option consiste à utiliser les outils de votre plate-forme pour automatiser l'installation. Sous Linux, vous pouvez créer un méta-package qui dépend de tous les packages dont vous avez besoin. Sous Windows, une chose similaire devrait être possible avec MSI ou similaire.
Modifier:
Dans l’idéal, au lieu de vérifier l’infrastructure d’aide, vous enregistrez les informations permettant à la compilation de générer l’infrastructure d’aide. C’est l’approche adoptée par exemple le système de compilation GNU (autotools, etc.) ou par Maven. C’est encore plus élégant, car vous pouvez (théoriquement) générer une infrastructure pour n’importe quel environnement de construction (pris en charge). Par conséquent, vous n’êtes pas tenu de le faire, par exemple. Un IDE spécifique et les paramètres de l'infrastructure d'assistance (chemins, etc.) n'ont pas besoin de dupliquer les paramètres principaux du projet.
Cependant, cette approche est également plus complexe. Par conséquent, si vous ne pouvez pas le faire fonctionner, j’estime que l’archivage de fichiers tels que les fichiers IDE est acceptable.
J'aime utiliser Virtual PC ou VMware pour virtualiser l'environnement de développement. Cela fournit un "environnement de développement" standard qui pourrait être partagé entre les développeurs. Vous n'avez pas à vous soucier des logiciels que l'utilisateur pourrait ajouter à leur système et qui pourraient entrer en conflit avec votre environnement de développement. Cela me permet également de travailler sur deux projets où les environnements de développement ne peuvent pas être tous les deux sur un seul système (utilisant deux versions différentes d'une technologie de base).
Utilisez puppet pour configurer votre environnement de développement et de production. L’utilisation d’un système d’automatisation de premier ordre est le seul moyen de faire évoluer vos opérations.
J'y ai pensé moi-même. Il existe certaines autres technologies que vous pourriez ajouter à la liste. Voici ce que je suis en train de configurer:
Sudo apt-get install acmecorp-Eclipse-env
ou Sudo apt-get install acmecorp-intellij-env
.apt-cacher
(proxy de paquet). En plus d'économiser de la bande passante, vos installations seront beaucoup plus rapides (les paquets étant mis en cache sur votre réseau local).A un endroit antérieur, nous avions tout (et je veux dire tout) en SCM (Clearcase puis SVN). Lorsqu'un nouveau développeur peut intégrer ClearCase | SVN, il a supprimé le référentiel. Cela gère également le cas où vous devez mettre à jour un lib/tool particulier car vous pouvez simplement laisser les équipes de développement mettre à jour leur environnement.
Nous avons utilisé deux repo pour cela, donc le code et les outils/config vivaient dans des endroits séparés.
Si vous utilisez OSX et travaillez avec Rails. Je suggérerais soit:
Il est toujours possible d'utiliser des machines virtuelles (voir, par exemple, VMWare Player ). Créez un environnement et copiez-le pour chaque nouvel employé avec la configuration minimale requise.
Je recommande fortement Blueprint de DevStructure. Il est open-source et votre cas d'utilisation est en fait la raison exacte à l'origine de la création du logiciel. Nos objectifs ont quelque peu changé, mais c’est toujours l’outil parfait pour ce que vous décrivez. En bref, vous pouvez créer des configurations de serveur réutilisables - une gestion simple de la configuration. J'espère que ça aide!
https://github.com/devstructure/blueprint (Blueprint @ Github)
Essayez DevScript sur http://nsnihalsahu.github.io/devscript . Sa commande unique, telle que devscript lamp
ou devscript laravel
ou devscript Django
. Dans quelques minutes, en fonction de la vitesse de votre connexion Internet
Si vous utilisez des machines dans une configuration standard, vous pouvez créer une nouvelle installation parfaitement configurée sur le disque. C'est une approche très populaire dans de nombreuses entreprises (et pas seulement pour les développeurs). Si vous avez besoin de systèmes d'exploitation configurés séparément, vous pouvez tar-bz2 tous les fichiers ajoutés et modifiés une fois qu'un système d'exploitation configuré est transformé en votre configuration souhaitée et il suffit de le désarchiver en tant que root pour créer votre environnement souhaité à partir de zéro.
si vous utilisez une version Linux, vous avez probablement un système de gestion de paquets: pense .rpm pour Fedora/redhat, ou .deb pour Ubuntu/debian. la plupart des choses que vous décrivez ont déjà des paquetages disponibles: svn, Eclipse, etc. script bash qui ajoute le rapport de la société à /etc/apt/sources.list (debian/ubuntu), puis appelle une commande du type,
/home/newhire$ apt-get update && apt-get install some complete package list
vous pouvez utiliser buildbot pour automatiser ensuite les versions régulières des packages de société qui changent souvent.