При установке пакетов psycopg2 и lxml easy_install радостно падал с криками:

 

unable to execute gcc-4.2: No such file or directory
error: command 'gcc-4.2' failed with exit status 1

 

Вполне логично, т.к. gcc у меня не стоял :(. Странно только что в Snow Leopard все работало. Немного полазив по инету нашел, что gcc ставится вместе с XCode, который ставится бесплатно из Mac App Store. Но и это не сразу помогло. Ниже привожу список шагов, которые понадобились для установки gcc и psycopg2 после этого.

 

  1. Из Mac App Store устанавливаем XCode.
  2. Добавляем в переменную PATH путь к gcc: export PATH=$PATH:/Developer/usr/bin
  3. Чтобы работало после перезагрузки и для всех пользователей прописываем этот путь и в /etc/paths

 


Хорошо когда код покрыт тестами. Хорошо когда кроме модульных тестов есть еще интеграционные, функциональные, UI-тесты и другие. Но должны ли тесты _всегда_ проходить успешно? Казалось бы, очевидный ответ - да. Но не все так просто...

Хороший тест должен выполняться успешно, когда все работает и показывать ошибку если где-то что-то не так. Он должен тестировать только то, что задумывалось и кричать(зчк) сообщать если ожидаемый результат (expetced result) отличается от того, что мы получили при выполнении нашей программы. Но и из этого правила есть исключения. 

К примеру, при написании когда, мы используем методологию TDD (Test Driven Development). В таком случае, только что написанные тесты никогда не выполнятся успешно, так как кода и функциональности, которую мы тестируем еще нет. Соответственно, если мы напишем n-е количество тестов, то наш билд нашего проекта всегда будет “failed”. Но при данном подходе это не должно мешать коммитить код в репозиторий и запускать все тесты автоматически на сервере CI. Вначале билд будет валиться, но с каждой реализованной фичей все больше тестов будет проходить успешно и ваш проект вскоре снова начнет собираться успешно.

Еще более интересная ситуация с тестами получается когда наше приложение использует сторонние библиотеки. Тут нам приходится работать с чужим кодом и/или со сторонней программой/API, исходников которой(го) у нас нет. Но тестировать-то надо. При этом у нас получаются интеграционные тесты, которые проверяют взаимодействие нашего кода с чужим.

В таком случае мы не можем контролировать работоспособность некоторых компонентов системы. Логично предположить, что тут тесты будут падать и это будет нормальным поведением. В большинстве случаев так и есть. Но бывают и другие ситуации:

Мы используем какой-то компонент SomeUsfulComponent, у которого должны быть две функции: FeatureA и FeatureB. И если хотя бы одна из них не работает, то тесты, которые проверяют взаимодействие нашей программы с этими функциями будут падать. А так как неработающие тесты на билд сервере - это поломанный билд, то дальше мы ничего делать уже не можем. Эта ситуация тоже вполне логичная. Вот только, например, мы в нашей программе можем обойтись без функции FeatureB. Как нам быть?

Тут, на мой взгляд, есть несколько решений данной проблемы. Привожу их в порядве “возрастания правильности”.

  1. Отключить тесты, которые падают из-за сторонних компонентов. Главный минус такого подхода - нужно помнить, что нужно когда-то проверить что эти тесты уже работают правильно и снова их включить.
  2. В процессе сборки проекта никак не реагировать на провалившиеся тесты. Если вы используете Jenkins, то на время можно сказать что при падении тестов продолжать дальше собирать билд. Минусы такого подхода - можно не увидеть, что упали другие тесты и продолжать спокойно работать.
  3. Учитывать в тестах, что FeatureB из SomeUsfulComponent бросает исключение NotImplementedException и в случае такого исключения говорить что тест выполнен успешно. В таком случае, как только FeatureB заработает корректно, наши тесты снова начнут падать и мы сможем быстро их исправить путем выкидывания ненужного уже кода.
  4. Сделать так, чтоб FeatureB работала :). Если это opensource проект, то тут все легче. Если исходников нет, но есть платная поддержка - получить рабочую версию как можно быстрее тоже можно, но не всегда. Иначе, скорее всего, ждать получится достаточно долго и обходится без нужной нам функциональности.


 

Первую версию этого поста я начал писать еще 2009-01-05 и в ней должно было описываться что такое CI и как настроить CruiseConrol.NET для ежедневных билдов. Пока писал - на ДОУ(линк на хоум пейдж) вышла аналогичная статья, т.ч. в то время моему посту не суждено было быть опубликованным. Потом я считал что Continuous integration является обязательным для любого проекта чуть более чем “hello world” и эта простая истина всем понятна. Как оказалось нет...

 

Что такое CI?

Continuous integration - дословно, это непрерывная интеграция. Вроде все просто и понятно. Осталось только разобраться интеграция чего и с чем. Если верить Википедии, то получаем следующее определение:

Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.

Если коротко - то это непрерывная интеграция различных компонентов проекта между собой и между внешним миром (автоматизированная установка новой версии ПО в среду обитания, максимально приближённой к дикой природе (зчк) production).

Что подразумевает под собой процесс CI?

Этот процесс может включать в себя такие шаги:

 

  • сборка проекта из исходников;
  • разворачивание/установка проекта (deployment);
  • тестирование (unit, интеграционные, нагрузочные и другие тесты).
  • создание отчета и уведомление команды о результатах предыдущих шагов.

Все эти шаги хотя и являются желаемыми, но не есть обязательными. За исключением, наверное, последнего - без него теряется фидбек о текущем состоянии проекта и о каких-то проблемах команда узнает не сразу. Но и этот шаг при желании/необходимости можно пропустить. Теперь подробнее о каждом из шагов. Шаги выполняются по порядку шаг 1 => шаг 2 => шаг 3 => шаг четыре. Если на шагах 1-3 произошла ошибка, то сразу переходят к последнему.

Сборка проекта из исходников

В типичном случае - по какому-то триггеру (время, новый коммит, нажатие кнопки “Старт”) сервер CI вытаскивает из системы контроля версии последние исходники, помечает текущую версию тегом с номером билда и компилирует проект. Все достаточно просто и понятно.

Разворачивание/установка проекта (deployment)

Этот шаг является подготовительным для тестирования. В случае если необходимо тестировать инсталлятор - шаг 2 объединяется с шагом 3.

Тестирование (unit, интеграционные, нагрузочные и другие тесты)

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

В зависимости от типов и количества тестов, на сервере CI может быть создано несколько разных типов проектов/билдов. Это может быть прогон unit-тестов при каждом изменении кода, запуск ночных билдов со smoke-тестами и, в случае прохождения smoke-тестов, будут запускаться более долгие по времени тесты - нагрузочное тестирование, проверка всех компонентов программы и т.д. 

Создание отчета и уведомление команды о результатах предыдущих шагов

Если билд успешно или неуспешно собран, то нужно как можно быстрее сообщить любым успешным способов команде разработчиков и/или QA. Красивые графики и отчеты являются как приятными плюшками, так и полезными данными для последующего их анализа.

Какие же преимущества нам дает CI?

Значительных преимуществ тут, на мой взгляд, 3 (конечно, их все можно объединить в одно - качество):

  • Автоматизация рутинных процедур сборки и запуска разных наборов тестов. Покажите мне разработчика, который _всегда_  запускает все интеграционные тесты, после каких-то изменений - врядли такого можно найти. И это я не говорю о ситуациях, когда есть возможность запустить тесты  только в определенное время, например, ночью.
  • Качество. Автоматическая сборка и тестирование - это значительный плюс к качеству разрабатываемого продукта.
  • Если сервер CI настроен верно, то у вас всегда будут самые свежие версии ваших продуктов, будет какие-то стабильная версия, когда все тесты проходят, можно будет легко и быстро найти кто, что и когда поломал.

Последнее что хочу скачать (что-то я часто начал говорить эту фразу), прежде чем начать настраивать это все, посмотрите на ваш проект и сделайте все не так, как написано в книге, а максимально адаптируйте решение для своего проекта.


Пару слов о UA Pycon 2011

Published 10/25/2011 by e0ne in Events

 

На прошедших выходных прошла уже вторая ежегодная конференция Ua Pycon 2011. Как видно из названия - конференция посвящена языку программирования Python. Людей было действительно много, наверное 300+. Официальных цифр я не видел/не помню. Также, в отличии от прошлого года, было целых 2 потока докладов, что является доказательством того, что конференция растет, а вместе с ней растет и Python-сообщество Украины, что меня очень радует. На фоне этого хочется создать свое маленькое или не очень харьковской сообщество, т.ч. кому интересно - пишите мне :).

 

Организация конференции была очень хорошей, место - в самом центре Киева, на майдане. Небольшой минус в виде плохого wi-fi ни капли не повлиял на всю атмосферу и мои впечатления от происходящего. Докладчики были как с Украины, так и из других стран. Чего стоят только Armir Ronacher и Andrew Goodwin!

 

Общение с докладчиками и другими участниками конференции - одна из лучших частей любой конференции. А доклады... Доклады - тоже хорошо, жаль что не получилось все послушать, с нетерпением теперь жду видео, которое организаторы обещали выложтить как только оно будет готово.

В этом году я решил попробовать свои силы в роли докладчика. Epic fail’а, кажется не было, но судить не мне. Доклад назывался “Django - инструкция по применению”, который некоторые назвали “Инструкция по НЕ применению”. Я говорил о случаях когда Django нам подходит, а когда не подходит.

Моя презентация на slideshare: http://www.slideshare.net/ivankolodyazhny/django-9855408

Небольшой фотоотчет на Google Picassa: https://picasaweb.google.com/105438605215260896047/UAPycon2011

 

До встречи на UA Pycon 2011


 

Сейчас только ленивый не писал об облаках. То, что раньше было просто веб-сервисом - сайчас SaaS. Вот раньше я пользовался gmail просто как почтой, теперь мне навязывают что это SaaS и поэтому это еще лучше. Как пользователю - мне все-равно как оно устроено.  Но вернемся ближе к теме поста и посмотрим какие облака вообще бывают.

Наиболее распространенные типы облаков (clouds) это (точные определения можно найти на Википедии, я говорю так, как выглядит это для меня):

  • SaaS (Software as a Service) - софт, как правило, веб-приложения, который работает где-то там на на сервере и не требует установки и/или мощного клиента. Такое себе арендованное ПО.
  • PaaS (Platform as a Service) - платформа для разработки ПО (Google App Engine, Azure). Позволяет с минимальными усилиями писать масштабируемые приложения. Тут провайдер PaaS берет на себя все или почти заботы по масштабированию приложения, обеспечению беспрерывной работы, администрированию серверов и т.д.
  • IaaS (Infrastructure as a Service) - грубо говоря, вам в аренду даются n-е количество серверов(облако), где при необходимости можно быстренько добавить и/или уменьшить количество серверов, памяти на них, объем винчестеров и т.д. Как пример IaaS - Amazon EC2.

Разработка любого облака - достаточно сложное и интересное занятие. Создать с нуля можно, но много уже есть готового. Opensource проектов для создания своего приватного клауда становится все больше. Openstack - один из таких проектов. Это IaaS платформа, написанная на Python. Если немного погуглить, то можно найти нечто похожее на Java и Ruby.

Описывать архитектуру и как работает Openstack я сейчас не буду. Я расскажу лишь о том, что нужно знать для комфортной работы с Openstack’ом. Мне, как веб-разработчику было достаточно быстро войти в процесс, т.к. проект требует спецефических знаний. Один лишь список модулей питона, которые необходимы для запуска одного из компонентов Openstack’а nova содержит 35 пунктов.

  • Python - ведь на нем все написано. Как правило, код достаточно простой и понятный, много комментариев. При написании кода соблюдается PEP8.
  • Знание linux-подобных ОС. Прежде всего, Openstack разрабатывался для работы под Ubuntu, но есть сборки и для других ОС. Под другими ОС имеется в виду Red Hat, CentOS, Fedora и т.д. И врядли он когда-нибудь будет работать под Windows - уж слишком много OS-specific мест наподобии работы с образами виртуальных машин, работа с сетью и т.д. Так же количество гипервизоров по linux значительно больше. Комфортная работа с консолью и понимание того как устроена ОС - навыки, без которых сложно будет работать.
  • Так как одной из основных задач Openstack’a является запуск виртуальных машин(серверов), то знание того как работает виртуализация будут большим плюсом.
  • Работа с сетью, понимание как что работает (VLAN, bridge-интерфейсы, маршрутизация и т.д.), уметь пользоваться iptables.
  • Git - проект хостится на GitHub’е.

Openstack в сети: http://openstack.org
GitHub: https://github.com/openstack