Рубрика «deployment» - 4

Инфраструктура системы пакетов для Python долго подвергалась критике как от разработчиков, так и от системных администраторов. Долгое время даже само комьюнити не могло прийти к соглашению, какие именно инструменты использовать в каждом конкретном случае. Уже существуют distutils, setuptools, distribute, distutils2 в качестве базовых механизмов распространения и virtualenv, buildout, easy_install и pip в качестве высокоуровневых инструментов управления всем этим беспорядком.

До setuptools основным форматом распространения были исходные файлы или некоторые бинарные MSI-дистрибутивы для Windows. Под Linux были изначально сломанный bdist_dumb и bdist_rpm, который работал только на системах, основанных на Red Hat. Но даже bdist_rpm работал недостаточно хорошо для того, чтобы люди начали его использовать.

Несколько лет назад PJE попытался исправить эту проблему, предоставив смесь из setuptools и pkg_resources для улучшения distutils и добавления метаданных в Python-пакеты. В дополнение к этому он написал утилиту easy_install для их установки. По причине отсутствия формата распространения, поддерживающего метаданные, был предоставлен формат 'яиц' [egg].

Python eggs – обычные zip-архивы, содержащие python-пакет и необходимые метаданные. Хотя многие люди, вероятно, никогда намеренно не собирали egg'и, их формат метаданных до сих пор жив-здоров. И все разворачивают свои проекты с использованием setuptools.

К сожалению, некоторое время спустя сообщество разделилось, и часть его провозгласила смерть бинарных форматов и 'яиц' в частности. После этого pip, замена easy_install, перестал принимать egg-формат.

Потом прошло еще немного времени, и отказ от бинарных пакетов стал доставлять неудобства. Люди всё больше и больше стали деплоить на облачные сервера, а необходимость перекомпиляции C-шных библиотек на каждой машине не слишком радует. Так как 'яйца' на тот момент были малопонятны (я так полагаю), их переделали в новых PEP-ах, и назвали 'колёсами' [wheels].
Читать полностью »

Вы все еще публикуете проект вручную? Тогда мы идем к вам

Continuous Integration для самых маленьких
Под катом гайдлайн по внедрению CI для .NET проектов «с нуля», включающий:

  1. Автоматические ежедневные сборки
  2. Уведомления о проблемах
  3. Интеграцию с баг-трекером и системой контроля версий
  4. Версионирование продукта
  5. Версионирование базы данных
  6. Автоматизированные выкладки и бекапы

Читать полностью »

Краткое предисловие переводчика.

Захватывающе интересная статья одного из разработчиков «GitHub Inc.» о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

То понятие, для которого на английском языке достаточно одного слóва «workflow», на русский приходится переводить словосочетанием — «рабочий процесс». Ничего лучше не знаю ни сам я, ни при помощи гуглоперевода — так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.

Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций на производстве» — и стану говорить именно о «внедрении» новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи о каком-либо «развёртывании» их.

К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.

Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

Простота его имеет несколько достоинств. Во-первых, людям проще понять его, так что они быстрее начинают использовать его, реже (или вовсе никогда не) допускают ошибки, требующие отката. Кроме того, не требуется скрипт-обёртка, помогающий следовать процессу, так что употребление GUI (и т. п.) не создаёт проблем.

Рабочий процесс Гитхаба

Читать полностью »

Новая версия WebMatrix 3: интеграция с облаком, TFS, Git, удаленный доступ к сайтам
Выпущена очередная версия бесплатного редактора кода и интегрированного средства разработки приложений WebMatrix 3. Среди функциональных возможностей WebMatrix 3 можно выделить следующие:

  • поддержка кода проектов HTML/CSS/JS, ASP.NET, PHP, Node.js;
  • встроенный редактор БД SQL Server и MySQL;
  • поддержка редакторами Jade, EJS, LESS, CoffeeScript;
  • галерея шаблонов популярных open source CMS: Joomla, Drupal, DotNetNuke, Orchard CMS, WordPress, phpBB и десятков других;
  • готовые стартовые проекты, в том числе Node.js c Express и Socket.io;
  • поддержка автодополнения и intellisense для ASP.NET, PHP, Node.js;
  • мобильная разработка: эмуляторы для мобильной веб-разработки, шаблоны мобильных сайтов;
  • инструменты анализа сайтов на вопросы SEO, ошибки, производительности;
  • система и галерея расширений от сообщества разработчиков;
  • поддержка галереи NPM-модулей для Node.js и репозитория Nuget для ASP.NET;
  • встроенная интеграция с системами контроля версий Git и TFS;
  • интеграция с облаком Windows Azure, публикация в облако проектов PHP, Node.js и ASP.NET, удаленный доступ к сайтам;
  • удаленный доступ к сайтам и публикация через протоколы FTP, WebDeploy, доступ к облачным размещениям.

WebMatrix 3 доступен бесплатно для загрузки на официальном сайте http://webmatrix.net/.

Быстрый обзор новинок третей версии доступен в этом видео на сайте Channel9. Для более подробного описания возможностей редактора обратитесь к этой статье и этому анонсу самой первой версии. Ниже вы найдете информацию о нововведениях в третей версии средства разработки.
Читать полностью »

Вам никогда не надо было быстро создать установщик для своего Java-приложения, но не хотелось тратить на это кучу времени, создавая свой собственный? Возможно, вы удивитесь, но в стандартной поставке JDK7 такой инструмент уже присутствует.
Читать полностью »

Привет!

В этом посте я буду говорить о выкладке Python-проектов: о том как положить на сервер код и все требуемые сторонние модули. Многие из нас сталкивались с проблемой развертки проекта на боевой машине, но на хабре об этом мало пишут; я хочу поделиться своим опытом.

image

Читать полностью »

От переводчика. Продолжая серию переводов про DevOps, в этот раз хочется поговорить о том, как делать НЕ надо. Мы сталкивались с этим, каждый раз, когда приходит что-то новое, например agile. Возникают культы карго, слышаться речи, что мы особенные и у нас все не так и так далее. Так давайте же попробуем избежать этого в случае DevOps.

Итак, вы хотите стать DevOps? Хорошо, но прежде чем начать, давайте взглянем на некоторые вещи, которые вы не должны делать.

В старые добрые времена, мы просто называли их «плохие идеи», но появилась дипломатия и политкорректность, ушел «мозговой штурм» и появился «idea shower», а вместе с ним и слово «анти-паттерны».

Если «паттерн» это правильный путь, то по своей сути «анти-паттерн» является неправильным — и поэтому, чтобы не дать вам пойти неверным путем, мы составили этот список (с небольшой помощью DevOps сообщества).
Читать полностью »

Наверняка, большинство из тех, кто разрабатывает или деплоит Python приложения, использует виртуальные окружения. В частности через virtualenv, написанный Ian Bicking.

Идея оказалась так хороша и распостранена, что нечно похожее теперь присутствует в Python 3.3 из коробки в виде модуля venv. Он почти такой же, как virtualenv, только немного лучше. Читать полностью »

Привет всем! Сегодня я постараюсь подробно описать процесс настройки Git-публикации для виртуальных машин в Windows Azure. Многие из Вас уже знают, что Windows Azure предоставляет разработчикам возможность публикации приложений в облаке посредством Git (подробное описание этого процесса можно найти здесь http://habrahabr.ru/company/microsoft/blog/150086/), но немногие знают что Git публикация функционирует за счет так называемого проекта Kudu.Читать полностью »

Perl — еще раз о деплое

Perl является скриптовым языком, с невозможностью компиляции в машинные коды, которые могли бы непосредственно выполняться на процессоре. Это создает проблему развертывания приложения на компьютере конечного пользователя. Еще сильнее эту проблему усугубляет присутствие в вашем приложении модулей из CPAN: заставить работать модуль на любой системе порой бывает проблематично.

Существует 3 подхода для решения этой проблемы:
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js