Налаштування розвитку Magento

це питання спрямоване на створення середовища розвитку. У мене є деякі конкретні вимоги:

1. Я хочу мати можливість використовувати своє рішення під Linux, Windows та Mac OS, оскільки люди нашої команди використовують усі ці ОС (наприклад, розробники переднього кінця використовують Windows / Mac, розробники заднього кінця в основному використовують Linux)
2. Мені потрібно використовувати модман
3. Мені потрібно використовувати композитор
4. Мені потрібно використовувати Github, а також мої приватні сховища Git
5. Мені потрібна відповідна IDE, як Netbeans або PHP Storm
6. Я хочу дуже хорошої роботи

Моя поточна настройка - це віртуалізоване зображення Ubuntu у Virtualbox. Усі три ОС можуть запускати Virtualbox, тому всі пункти 1) - 5) задоволені.

Однак на даний момент я не повністю задоволений 6). Особливо це стосується запуску рішення з Ubuntu 12.04. Virtualbox здається набагато стабільнішим та чутливішим у Windows 7. Однак багато людей в нашій команді використовують Linux, тому я хотів би вдосконалити рішення.

Хтось має порівнянні налаштування у VMWare або, можливо, навіть docker.io і може повідомити, чи працює він стабільніше? Або хтось має інші порівнянні рішення / ідеї?

Я використовую vagrant, git та деякі сценарії побудови на phing. Базисна машина, що працює на бродяжній машині, працює з веб-сервером, git використовується локально для відстеження змін у моїх розширеннях та створення сценарію, що використовується для оновлення /var/wwwкаталогу на моїй бродячі (ну, власне, він використовується скрізь, де мені потрібно створити середовище).

Фінг

Напевно, найцікавіша частина - фінг, які працюють як модман + композитор для мене. У ньому визначено кілька цілей, включаючи збірку, налаштування та встановлення.

Ціль збірки завантажте певну версію magento (вказану в конфігурації збірки) з внутрішнього веб-сервера та витягніть її у каталог збирання. Потім запустіть інші цілі, які встановлюють дозволи для файлів, і очистіть кеш. Потім він створює посилання на всі файли у вихідному каталозі. В результаті я готую всі файли до використання в моєму каталозі збірки. Якщо основні файли magento, які вже знаходяться в каталозі збірки, вони пропускають завантаження та просто оновлюють посилання, тому я використовую цю ціль для відновлення середовища кожного разу, коли мені потрібно оновлювати символьні посилання. Для бродячої машини джерело каталогу знаходиться в /vagrant/src(загальна папка), а каталог збірки є /var/www.

Встановити цільову завантаження і дамп бази даних імпорту для певної версії Magento. Потім запустіть ціль налаштування.

Ціль налаштування просто створить файл local.xml з усіма налаштуваннями.

У моїй компанії ми використовуємо інструменти тестування модулів та інструменти CI, тому цей спосіб створити середовище magento дозволяє нам протестувати наші розширення на різних версіях magento та запускати їх із встановленням та без нього.

Я створив "ярлик" на бродяжній машині, який спрощує доступ до створення. Наприклад, для відновлення проекту мені просто потрібно ввести vagrant ssh -c magebuildі він автоматично запустить phing у /vagrantкаталог.

Тоді я призначив цю команду певній комбінації клавіш у моєму IDE PHPStorm, і тепер я можу відновити проект, просто натиснувши Alt + B у своєму IDE. Але оскільки я використовую посилання, це не дуже часто.

Бродячий

Ящик для бродячих - це моя власна коробка з Ubuntu 12.04 на борту, це фактично просто стандартний точний 12.04 із усім програмним забезпеченням, попередньо встановленим + ярлик та деякою конфігурацією. У бродячий файл я помістив лише налаштування переадресації портів, приватну мережу, щоб мати можливість використовувати xDebug і класти ярлик для складання положень.

GIT

У git я відстежую лише свої файли розширень, build.xmlдля phing та Vagrantfile. Отже, кожен, хто хоче створити середовище, може просто клонувати сховище та запускати бродячі. Тоді він отримає ВМ і буде готовий до роботи. Весь цей процес займає 1-2 хвилини. Якщо ви хочете створити проект локально (без використання VM), можна запустити phing build install.

В даний час моїм середовищем розробки є Ubuntu v12.04 з VMWare. Я працюю повністю всередині VM, з повним графічним інтерфейсом і використовую лише обмін файлами samba в Ubuntu, якщо мені потрібно дістатись до файлів з моєї ОС хостингу, яка є Windows 7. Я звичайно отримую доступ до картографічного мережевого диска через внутрішній IP VM через NAT для підключення до VM. Використання інших рішень виявилося набагато повільніше, як спільні папки VMWare. У мене це вимкнено в налаштуваннях зображення VMWare. Однак я встановлюю інструменти VMWare для легкої копіювання / пасти на свою хост-машину і навпаки.

Як зазначив Маттіас Цайс, будьте уважні у виборі мережевих / спільних папок з вашим VM, оскільки деякі виявляться проблематичними.

Я був попереднім користувачем VirtualBox, але виявив, що VMWare є більш стабільним і працює приємно (принаймні для мене). Однак я б провів власні тести, щоб найкраще відповідати вашим потребам та вимогам, тобто. Vagrant використовує VirtualBox.

IDE: Я використовував Netbeans досить широко як мій вибір IDE, але з тих пір перейшов до більш легкого рішення як Sublime Text 2 . Я рідко відкриватиму Netbeans, як головним чином для цілей X-Debug та полегшення Refactoring. Netbeans, PHPStorm, Eclipse і т. Д. - все IDE, засновані на Java, і вони можуть бути дуже голодними.

ТЕХНІЧНЕ ЗАБЕЗПЕЧЕННЯ: Щоб додати більше, обладнання завжди матиме ключову роль у продуктивності (очевидно). Якщо ваші розробники досі використовують жорсткий жорсткий диск, я б хотів інвестувати в SSD для них. Оскільки Magento має дуже велику кількість файлів / папок, це значно прискорить роботу розробників. Під час розробки: з відключенням кешування та Хоча просто обхід дерева папок у SVN / GIT або вашому IDE. Надання вашої оперативної пам'яті достатньою мірою також важливо.

Моя хост-машина: Samsung SSD 512 Гб місця на диску, Win7 (64 біт), 8 ГБ оперативної пам’яті, i7 2,4 ГГц (8 ядер)

Моя машина VM: Samsung SSD, 30 Гб місця на диску, Ubuntu 12.04 (32 біт), 3 ГБ оперативної пам’яті, i7 (виділено 4 ядра).

ЗАПИТАННЯ НА ЗАПИТАННЯ: Найбільше питання - створити одне зображення VM для розробників, яке є легким і багаторазовим для використання в декількох проектах, або створити зображення на проект. Раніше я намагався робити менші віртуальні машини на основі проекту, однак перенастроювання постійно йти з моїм робочим процесом стало занадто великим завданням, а тепер використовую одну більшу машину управління та намагаюсь зробити кожен проект максимально ізольованим.

Підтримання ОС, IDE, стека LAMP, оновлень / конфігурацій тощо може стати справжньою справою, якщо вибраний маршрут декілька VM на проект. В кінцевому рахунку, це призводить до більш тривалого часу розробки (і ще гірший час, що не підлягає оплаті для місцевих налаштувань навколишнього середовища).

Це також виявилося корисним, оскільки я швидко зміг отримати доступ до інших файлів проектів без необхідності відкривати нову віртуальну машину та ще більше розрізати обладнання для свого хоста. Недоліком ідеально є те, що я хотів би, щоб кожен проект був відхилений від інших проектів, щоб запобігти виникненню непередбачених проблем із довкіллям (наприклад, php.ini, my.cnf, httpd.conf тощо). Поки що компроміс із доступністю всіх доступних проектів виявився більш винахідливим.

Знову ж, це відповідає вашим вимогам та потребам, тому оцініть їх перед рукою.

ЗВОРОТНІ ЗВ'ЯЗКИ: Це призводить до зворотного зв'язку Отримайте якомога більше коштів від розробників. Зрештою, їхні вимоги повинні бути виконані, а їх проблеми зрозуміти, перш ніж можна буде створити і ввести належне рішення. У кожного різні робочі процеси, і не всім комфортно працювати в ОС, яку ви можете обрати для розробки. Моє правило - нехай розробник обрав ОС та IDE, з якими вони найзручніші та найкращі. Тож навіть легкий безголовий VM для Linux може виявитися корисним для їхніх потреб, але, очевидно, може виникнути проблема спільного використання папок у локальній мережі між Host та VM.

ПОРТИВНІСТЬ: Я також грав з ідеєю зберегти своє зображення VM на чомусь схожому на Dropbox, щоб я міг легко отримати доступ до нього в будь-який час, коли мені це знадобиться. Оскільки такі сервіси, як Dropbox, поступово порівнюють те, що зберігається, здавалося логічним, що синхронізуються лише зміни, які я змінив. Однак це виявилося не так, тому що я вважаю, що це стосується внутрішніх даних щодо збереження файлу зображень, і я б чекав цілий день / ніч лише для того, щоб мій ВМ синхронізувався.

ПРИМІТКИ: Чим більший простір приводу, призначений для VM, тим більше зображення стане, майте це на увазі, коли розповсюджуєте зображення своїм розробникам. Фронт завантаження файлів проекту на проект може бути надмірним, і я залишаю це для кожного розробника, щоб налаштувати після створення іміджу.

Ешлі Шродер має дещо стару пов’язану статтю, яку добре читати, а також деякі коментарі Фомана і Коліна

• http://www.aschroder.com/2010/07/structuring-your-magento-project-for-engineering-not-hacking/

Сподіваємось, це допоможе зрозуміти ваш перелічений проблематичний номер, №6.