Processus de stream de travail Magento avec git

J'ai codé des sites Magento en utilisant des tâches cron pour gérer les sauvegardes, mais cela devient un peu maladroit lorsque je tente de revenir aux versions précédentes du site. Je dois essentiellement creuser à travers les sauvegardes et revenir manuellement les choses en arrière. J'ai lu sur git et j'aime l'idée d'être capable de documenter mes changements à travers le cycle de développement et de revenir aux choses spécifiques que je change avec quelques commands.

Actuellement, j'ai deux twigs dans mon repo local (master, develop). Je fais essentiellement tout mon développement dans la twig de développement et fusionne tout à la twig maître quand j'en ai fini avec un set spécifique de tâches et de pousser les choses à mon repo de gitbucket à des fins de sauvegarde et juste pour entrer dans l'habitude d'utiliser un repo à distance.

Je suis nouveau à git donc ce bruit suffit-il pour mon scénario ou quelqu'un peut-il reorder un bon process de workflow pour un magasin one man utilisant git avec Magento? Merci.

Solutions Collecting From Web of "Processus de stream de travail Magento avec git"

Nous utilisons le model GitFlow pour notre développement Magento. C'est similaire au vôtre mais avec une twig supplémentaire pour un site de mise en scène. De plus grandes tâches de développement / corrections sont également complétées dans des twigs séparées pour s'assurer que le développement est toujours raisonnablement stable. Nos sites de transfert sont un repo git avec la twig de transfert extraite et les sites de production ont la twig principale extraite. Lorsque nous sums prêts à déployer des modifications sur la mise en scène, nous les fusionnons vers une mise en scène sur nos machines locales, puis nous envoyons le tout vers un repo Git central, puis nous tirons sur le server. Fonctionne bien, mais vous devez faire attention à app / etc / local.xml car cela devrait être différent dans chaque environnement. Vous voudrez également vous assurer que des choses telles que les dossiers médias et var ne finissent pas dans votre repo git.

Github publie un .gitignore pour Magento, mais le problème est qu'il exclut tous les files core de Magento. Vous vous retrouvez avec un bon référentiel propre qui contient uniquement vos modifications, mais pas quelque chose qui est déployable. Nous utilisons un .gitignore beaucoup plus simple qui exclut simplement media var et app / etc / local.xml. Nous utilisons généralement une seule télécommand (par exemple Github) et déployons à partir de là.

Sur les servers sur lesquels nous déployons, nous avons généralement un access shell et git installé donc le deployment est une question de ssh'ing et d'exécution d'un git pull (ou fetch & merge) à partir de la télécommand normale.

Nous maintenons les sites de transit en tant que twig distincte dans git, et les déployons de la même manière. Donc, notre process ressemble à Développer dans une twig d'entité et merge en "développer" une fois terminé. Lorsque les tests d'intégration sont terminés, fusionnez "develop" (ou cerise-pick) à "staging" et déployer. Lorsque vous êtes prêt pour la production merge "staging" (ou cerise-cueillir des changements individuels) à la twig "maître". C'est fondamentalement GitFlow mais la twig "préparation à la sortie" est longue.

Comme le tutoriel Sonassi lié dans les commentaires le souligne, le problème avec les médias symlinking est que si vous supprimez un file multimédia de la production, vous obtenez un lien brisé dans la mise en scène et vice versa. Au lieu de relier les deux, nous mettons à jour le code de transfert de git, mais sinon, nous lançons les sites de transfert et de production séparément. Si nous avons besoin de nouveldatatables dans la mise en scène, pour une raison quelconque, nous allons prendre une copy du support de production et de la database et la restaurer sur le site de transit.

Le model Gitflow utilise des numéros de version pour les labels de version, si vous avez des numéros de version sur lesquels l'équipe est d'accord pour les versions, utilisez-les. Sinon, si vous avez une sorte de plan d'étape ou de système de sprint auquel vous travaillez et que vous pouvez identifier une version de cette façon, cela fonctionnera également. Si tout le rest échoue, nous utilisons la date / heure du deployment. par exemple

git tag -a deployed-`date +%Y%m%d-%H%M` -m "Code release at `date`"