Каждый веб-проект запускается с наилучшими намерениями: локальный запуск, модульное тестирование, простота развертывания, подготовка серверов. По мере продвижения проекта некоторые из этих тонкостей уходят на второй план, а именно: возможность работать локально.
Никогда не позволяйте этому случиться с проектом. Вы не можете позволить себе стоимость этого.
Это происходит со всеми проектами по той же причине. У вас есть какая-то ошибка, которую нужно исправить, или вы работаете над какой-то функцией, которую НУЖНО вывести, и вы решили просто запустить vim при подготовке / производстве, исправить ее и внести изменения позже.
В конце концов (и это не займет много времени) это создает среду, которая не может быть запущена на локальной машине. Это даже более вероятно произойдет, если вы используете Windows.
Там могут быть другие вещи, чтобы рассмотреть, хотя. Серверы почти всегда отличаются операционной системой и имеют разные зависимости. Они, вероятно, не способны обеспечить себя автоматически. Средам разработки также может потребоваться запустить отдельный процесс (например, рабочий поток или solr или что-то в этом роде)
Поддерживать работу проекта на полях разработчика — непростая задача.
Почему проект, работающий локально, так важен?
Когда проект может быть запущен только на сервере, вы должны сделать несколько вещей, которые вам не нужно делать в локальном окне.
- (Вообще) у вас не может быть своего собственного текстового редактора, особенно если текстовый редактор не является консольным
- Вы, вероятно, не используете автоматизированные тесты
- Кто-то еще развертывается на этом сервере, вся ваша работа ушла
- Вы должны SSH в
- Каким-то образом вы должны передавать файлы туда и обратно. Большинство разработчиков будут использовать свою собственную память или копировать-вставить, лучшие разработчики будут использовать rsync, но даже rsync отстой здесь
- Перезапустите сервер после изменения (или включите перезагрузку кода)
В конце концов, все занимает больше времени. Когда я пишу такой код, я, вероятно, менее чем наполовину настолько эффективен, насколько мог бы быть. Не так много дополнительных шагов, это то, что делает жизнь инженера несчастной.
У большинства компаний, в которых я работал, была эта проблема, и это одна из вещей, которая в конечном итоге заставила меня перестать работать на них. Льготы и деньги хороши, но с этим приходится сталкиваться каждый день, с чем лично я не могу иметь дело очень долго. Это разрывает мое здравомыслие.
Это очень поможет с посадкой. Так как новым инженерам не нужно будет так же быстро набирать скорость. Им также может быть удобно бездельничать в их собственной среде.
Как вы можете избежать этой проблемы?
Честно говоря, избежать этой проблемы нелегко. Требуется серьезное посвящение и сила воли. Опять же, не стоит от этого отказываться.
Вот что вам нужно сделать:
- Быть в состоянии создать новую среду разработки очень легко
- Быть в состоянии обеспечить новые серверы легко
- Сделать производство как можно ближе к среде разработки
- Используйте перезагрузку кода в среде разработки
- Использовать мерзавец
Есть некоторые инструменты, чтобы помочь с этим. Те, о которых я собираюсь упомянуть, ориентированы на ruby, но я знаю многих разработчиков на python и php, которые их используют, и они прекрасно работают.
бродяга
Vagrant — это оболочка командной строки для виртуальной коробки. Звучит совершенно скучно и бесполезно, но оно разработано специально для решения большинства проблем, которые я только что упомянул. Он может не только запустить дистрибутив vanilla linux в 2 команды, но и обеспечить их!
Поэтому, если у вас есть Vagrantfile в корневом каталоге вашего проекта, новому разработчику нужно всего лишь набрать ‘vagrant up’ в командной строке, и он сможет запускать полностью подготовленную, готовую к работе производственную среду.
Он также свяжет локальный каталог проекта с каталогом at / vagrant на коробке, поэтому любые изменения, внесенные локально, сразу же вступят в силу на коробке. Он также настраивает переадресацию портов, так что вы можете просто нажать 127.0.0.1:3000, и вы попадете на виртуальную машину.
Он может использовать либо сценарий bash, либо chef или puppet (или комбинацию) для обеспечения.
Я не использую его в каждом проекте, для его настройки требуется время. Большинство моих проектов будут работать на OSX. Однако, если вы используете Windows, вам НУЖНО это.
Вы также можете возиться с сумасшедшими вещами, такими как обновление всех ваших драгоценных камней, пробовать следующую версию django, что вы хотите. Вы чувствуете себя комфортно, зная, что можете разрушить всю окружающую среду и восстановить ее.
Еще один бонус: используете ли вы шеф-повара, марионетку или обычный файл, у вас также есть возможность подготовить производственную машину. Загрузите новую установку ec2, запустите средство инициализации и получите готовую к работе машину, которая работает так же, как среда разработки.
Шеф-повар + кукольный
Chef и Puppet — новые крупные сделки в сообществе Unix. Они предоставляют серверы. Я использовал оба, и ненавидел оба. Их трудно выучить по моему мнению. Я использовал оба достаточно, чтобы обойтись, но это не приятный опыт, как мне кажется, так и должно быть.
Мне, наверное, просто нужно узнать их лучше.
Тем не менее, они лучшие из тех, что я знаю, потому что вы инициализируете серверы.
Капистрано + Ткань
Capistrano и Fabric являются инструментами развертывания. Когда ваш сервер подготовлен, запустите его, чтобы развернуть / запустить / остановить / перенести dbs, что вам может понадобиться. Используйте один из них.
мастер
Форман очень прост. Все, что он делает, это позволяет вам иметь файл, как это
web: bundle exec thin start -p $PORT worker: bundle exec rake resque:work QUEUE=* clock: bundle exec rake resque:scheduler
И если вы запустите ‘foreman start’ в командной строке, он будет работать так:
Изображение из «Представляющего мастера Дэвида Доллара»
Простой способ убедиться, что сервер запускается одинаково для всех, а также запускаются все зависимости. Это значит, что вам не нужно открывать дополнительное окно команд для вашего рабочего сервера.
Резюме
Как многие знают, я большой поклонник Heroku. Одна из моих любимых вещей в Heroku — вы не можете получить доступ к серверу. Я знаю многих инженеров, которые расценили бы это как недостаток, но я вижу это как предотвращение того, что я буду стрелять себе в ногу.
Таким образом, есть несколько советов по поводу того, что проект может сделать для инженера. Как я уже сказал, решить эти проблемы нелегко, поэтому я только рассказал вам, какие инструменты вам нужны, и где можно найти дополнительную информацию о них.
Потратьте время, чтобы использовать их и изучить их, оно того стоит.
Источник: http://jeffdickey.info/keep-your-project-running-locally