Development workflows - по-лесно въвеждане в проекта

[RadoRado]

Здравейте на всички 🐼

Тъй като това е open source проект и шансът да има нови хора, които да помагат е голям.

За да спестим време на всички, според мен ще е добра идея към ckan-install, всеки, работил по CKAN-а да разпише неговия dev workflow.

Например, @antitoxic ползва Vagrant. Гледам, @mitio също има commits, а следните хора са писали в документа за track–ване на време, че са го подкарали:

• @peperon - "Setup на проекта на нова виртуалка. Като цяло имах проблеми да го инсталирам на Ubuntu 14.04 и го setup-нах на старата LTS верия, 12.04"
• @Станчо - "Setup на проекта. Подкаран, но имам проблем когато се логна. Подозирам куки/домейн/права, но не съм го преодолял все още."
• @syndbg - "Setup на проекта. Успешно подкаран чрез инсталационните инструкции в CKAN docs, но с известни разминавания от това, което се използва в governmentbg"

Това би спестило време на новоидващите и ще им помогне да не борят вече преборени проблеми.

Към момента, аз се опитвам да го подкарам с Vagrant, като след това ще опиша какви са ми били стъпките, за да стигне до нещо работещо - не само като CKAN, но и като цялостен development workflow.

Като допълнение, може да се разпише (ако вече няма):

• Как се run-ват тестовете?
• Как може да се вземат тестови данни за local development?
• Как става deploy-ването към staging? Евентуално, да се автоматизира с capistrano || fabric || нещо друго

Мнения? 🐼

[antitoxic]

Ето с какво мога да допринеса:

1. Силно препоръчвам всеки, който има проблеми да следва ckan-install инструкциите в Debian Wheezy виртуалка. Точка по точка. Не сменяйте директории. Не замествайте инструкция с подобна. Просто както е написано. Днес инсталирах чрез скрипта, понеже бях доста учуден на трудността, която се среща. Имах 0 проблеми в инсталацията. Разбира се има вероятност, че аз съм мега-късметлия и какъвто и бъг да има в скрипт, той при мен не се проявява, но шансът за това ми се струва доста минимален.

   Ето и препоръчания basebox: https://github.com/governmentbg/ckan-install/blob/master/debian/vagrant.sh#L3

   Единственото нещо, което на моята машина направих преди да пусна скрипта ( @syndbg нямаше този проблем ) е да регенерирам locales във виртуалката. Това е заради спецификата на моята хост машина, където locale е bg_BG.UTF-8. Анто е с английски и нямаше проблеми. Регенерирах чрез:

   sudo apt-get purge locales
   sudo aptitude install locales
   sudo dpkg-reconfigure locales
   

   Ето версията на config.sh, след моите персонални редакции:

   !/usr/bin/env bash
   CKAN_CONFIG_FILENAME="production.ini"
   CKAN_CONFIG_DIR=/var/www/ckan/config
   VIRTUALENV_DIR=/var/www/ckan/virtualenv
   UPLOADS_DIR=/var/www/ckan/data
   OWNER_USER=www-data
   OWNER_GROUP=www-data
   MAX_RESOURCE_SIZE_IN_MEGABYTES=200
   
   CKAN_INSTANCE_NAME=opendatabulgaria # only latin lowercase + underscores allowed
   CKAN_DOMAIN=local.opendata.bg
   CKAN_URL=http://local.opendata.bg
   CKAN_TITLE="Open data portal"
   
   LOCALE=bg
   LOCALES_ORDER="bg en"
   
   FAVICON_RELATIVE_URL=/favicon.ico
   
   CKAN_REPO_TAG=https://github.com/governmentbg/ckan.git@master
   
   CKAN_THEME_NAME=bulgarian_theme
   CKAN_THEME_REPO_TAG=https://github.com/governmentbg/ckan-bulgarian-theme.git@master
   
   POSTGRES_NEW_USER=ckan_default
   POSTGRES_NEW_READONLY_USER=datastore_default
   POSTGRES_PASS=samplepassword
   POSTGRES_DBNAME=ckan_default
   POSTGRES_DATASTORE_DBNAME=datastore_default
   
   SOLR_SETUP=auto
   SOLR_PORT=8983
   SOLR_URL=http://127.0.0.1:8983/solr
   
   DATAPUSHER_REPO_TAG=https://github.com/governmentbg/ckan-datapusher.git@master
   DATAPUSHER_URL=http://0.0.0.0:8800/
   # Not implemented. Should we have separate venv for datapusher at all?
   #VIRTUALENV_DATAPUSHER_DIR=/usr/lib/ckan/default
   
   [email protected]
   [email protected]
   [email protected]
   SMTP_HOST=localhost
   SMTP_TLS=True
   SMTP_USER=samplesmtpuser
   SMTP_PASS=samplesmtppass

   От там насетне е въпрос на dev настройка. Примерно, днес си настроих минимален Vagrantfile:

   Vagrant.configure(2) do |config|
   config.vm.box = "debian"
   config.vm.network "forwarded_port", guest: 80, host: 8080
   config.vm.network "public_network"
   end
   

   и си сложих 127.0.0.1 local.opendata.bg в hosts на хост машината, така че http://local.opendata.bg:8080 ми зарежда ckan.

2. Подкарването на тестовете е поел @peperon

3. И @banzsh ме пита как се разработва локално пакет инсталиран с pip. И аз не знаех. Търсих в google. Първият резултат. И най-високо оценения отговор там ми даде яснота за 10 минути: pip install -e. Пример ползвайки наученото от google и guides:

   sudo su - www-data
   source ....<path to venv>/bin/activate # където сте избрали да е virtualenv-a при конфигуриране
   pip uninstall ckan
   git clone [email protected]:obshtestvo/ckan.git
   pip install -e ./ckan
   

   И така за всеки пакет, над който ще работите. Ако не е ясно питайте допълнително тук или в gitter чата.

4. За deployment-a към staging. В момента искам всеки да започне да работи и оправя issues. Тоест няма прекарано време в това да установим deployment процес по-сложен от ssh staging, pip uninstall, pip install. Когато и ако deploy-вамe толкова много, че това да е проблем, ще го подобрим.

Като цяло моля, имайте предвид че:

1. Има предоставен скрипт и инструкции за старт, които днес проверих че работят. Би трябвало да разбирате, че всяко отклонение от тях (примерно това да инсталирате на различна от дебиан машина и тн) е отклонение за вашето удобство и риск. Когато мога - помагам в такива ситуации, но се надявам да разбирате, че това го правя изцяло за вас. По проектът може да се работи още сега. Ако произлезнат проблеми от предоставения setup, те ще са поне след като вече сте видяли как работи и вече всеки е подхванал поне 1 issue.
2. Избягваме (аз и @mitio) да даваме setup инструкции още в началото, за да видим как всеки се справя. Това е начин за нас да видим как всеки подхваща проблем.
3. Реитерирам: При проблем, вижте дали има инструкции и следвате ли ги точно, вижте дали някой друг няма същия проблем (по чат, по мейл), вижте contribution guidelines

[peperon]

За това как да се пуснат тестовете -> #30. Update-нах issue-то с това как го направих аз.

[peperon]

Update: Обновин отново issue #30 с това как се пускат тестовете на datapusher.

[RadoRado]

@antitoxic златен си 💋

Ще го пробвам и ще пиша обратно в тази карта!

[marchev]

@ALL Има ли възможност пречка да се направи Vagrantfile, който в комбинация с bash script да setup целия environment, така че да не се налага всеки да минава на ръка през всички стъпки? Бих могъл да помогна с нещо подобно.

[antitoxic]

@marchev, да 3.

1. Текущия начин на setup, чрез конфиг дава представа за най-важните елементи в проекта (пътища, репота, търсене, бази). Това е желан ефект.
2. scope, фокус, време. Проектът е за подобрения в портала и всичко друго идва второстепенно ако остане време.
3. Някои от участващите в проекта предпочитат проектът да върви на хост машината.

[marchev]

@antitoxic Според мен някакво README, което очертава тези елементи, би било по-подходящо.
Относно т. 2 - бих могъл да отделя време за такъв тип автоматизация. т. 3 - по този начин се губи портативността. В случая, според мен, технология като Docker би била по-подходяща от Vagrant, т.к. се избягва тежестта от вдигането на цяла VM-ка, като същевременно се постига портативност. Реално нещата могат да се направят така, че напрактика едни и същи контейнери, да се използват и при dev и при prod, като единствената разлика би могла да бъде конфигурацията (db credentials, etc.)

[antitoxic]

@marchev лимитирани са силите за координация. Работещите по проекта нека се фокусират по развитието и бъговете, независимо как го развиват локално.

Да, губи се portability, но минимално, а екипът е доволен и продължава. + Docker е по-леко от 1 виртуалка с вагрант само на unix, т.е. пак ще има OS разлики.

Нека направим така: Който има желание и има свободно лично време, и му е кеф, нека разцъква. Ще се приемат pull request-и.

@RadoRado изяви подобен интерес. Ако решите join forces 💥

PS: пример за време са и тези дискусии. Стойностни са. Едновременно с това, те ядат от координацията по други неща. Засега просто не е приоритет.

[RadoRado]

@marchev аз съм надъхан да го направим това, защото ще свали летвата за вход в проекта по много важен параметър - времето, за да подкараш и да почнеш да бориш issue-та.

Хайде ще се доразберем по gitter 🐼

[RadoRado]

Така, вчера имах известни (големи) драми с OS-а ми и респективно Vagrant, за това си взех чиста виртуалка с Debian и всичко тръгна почти от първият път.

Имах следните проблеми:

• Не успя да намери JAVA_HOME, но install script-а каза къде да вляза и да го въведе, след това нещата с jetty се оправиха
• pip install -e / pip uninstall са малко tricky. Това, което сработи при мен бе да махна ckan от /venv_path/src/ и директно там да клонирам и да кажа pip install -e ./ckan - тогава нещата тръгнаха.
• Преди това ми хвърляше 500 с DistributionNotFound: ckan

Това, което ще направя в свободното си време (извън track-ваното за проекта) е да си оправя моят OS (да мина към LTS) и да наглася един Vagrant image с всичко готово и setup-нато за dev.

@marchev може да се разберем за удобно за мен и за теб време да итерираме в/у този проблем 👍

За сега оставям картата отворена. Като имам готов Vagrant и съм го тествал с 3rd party човек, ще пиша пак тук 🐼

[RadoRado]

Малък update от мен, как работя в момента:

1. Вдигнал съм си една Debian виртуалка в DigitalOcean
2. На нея script–а върви без проблеми.
3. Разработвам локално.
4. Имам един sync.sh който през scp ми мята променените файлове на сървъра.

Решението е доста dirty hack, но все още не съм имал възможност да преинсталирам до LTS версия на Ubuntu, за да се преборя с Vagrant–а.

[mihail-ivanov]

Ако не искате да използвате виртуална машина и искате да си debug-вате локално можете да използвате тези скриптове: ckan-helpers

Може да се инсталира на всякаква машина, но първо трябва да се инсталират dependencies, които са посочени в документацията на CKAN. Също така се стартира локален сървър с paster и не е нужно да се инсталира apache или nginx.

Самия install скрипт създава локална директория с име INSTANCE_NAME и инсталира всичко вътре. В директория INSTANCE_NAME/src/ckan създава един файл (run_dev.sh), който стартира приложението (преди това сменя схемата на jetty, за да може да се работи с различни инсталации на една и съща машина).

Друго, което може би трябва да се смени - на Ubuntu 15.10 jetty service-a се казва jetty8. Така го оставих в скрипта, но може да се наложи да го смените, преди инсталация, за да работи правилно.