Я вот тоже сначала заморочился с виртуалкой, хотя меня разубеждали, а потом просто поднял себе микроинстанс в Amazon EC2, сейчас понимаю что это более правильный выбор.
Поищите в моих комментах, я писал как заставить обновиться. Правда, есть вероятность, что после этого придётся удалить и вернуть свой гугл аккаунт на телефоне (без фектори резета), иначе некоторые приложения в маркете обновляться не будут. Я вчера сделал, единственное неудобство что после этого некоторые программы типа Google+ спросят хотите ли вы для них использовать только что добавленный аккаунт, нужно согласиться.
Вывод по HDMI сейчас поддерживает максимальное разрешение 1280х720. Соответствующий патч для поддержки полноценного FULL HD производитель должен добавить в следующих обновлениях прошивки.
Всё это китайское барахло как из каменного века — в топку.
Я имел в виду другое, есть ключ, я ввожу его на неком компьютере, как организуется поиск компьютера, с которым нужно спарить тот, на котором я ввожу ключ?
Нашел причину своей проблемы — два моих компьютера находятся в одной локалке, но один на Wi-Fi, другой на кабеле и эти две подсети не видят друг друга, хотя обе имеют доступ в интернет.
Как только оба компьютера оказались на Wi-Fi — синхронизация заработала.
— Генерирую код на одном первом компьютере, даю папку.
— На втором ввожу код и указываю папку.
— На первом в списке Devices появляется запись второго компьютера
— На втором в девайсах первого не видно
— Синхронизация не идёт
Вероятно это не связано с RealSync, но так как я не администратор — не могу пока найти решение проблемы, может подскажете:
Для хранения сайтов я на сервере создал от пользователя root директорию /www/project
Создал группу webdev, добавил в неё пользователя fog, от которого хожу через RealSync.
Поставил директориям (www и /www/project) группу webdev и группе дал права rwx — clip2net.com/s/5oZ1uI
Что получается:
Файлы синхронизируются, т.е. по крайней мере попадают в директорию, но в консоли такая ошибка (в цикле):
*****
rsync: failed to set times on "/wx/test/.": Operation not permitted (1)
sent 4267 bytes received 55 bytes 2881.33 bytes/sec total size is 688926 speedup is 159.40
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]
[11:25:55] Rsync exited with code 23, retrying...
[11:25:55] Detected changes in more than 10 objects. Running rsync: it's faster.
sending incremental file list
./
rsync: failed to set times on "/wx/test/.": Operation not permitted (1)
sent 4267 bytes received 55 bytes 2881.33 bytes/sec total size is 688926 speedup is 159.40
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]
[11:25:56] Rsync exited with code 23, retrying...
[11:25:56] Detected changes in more than 10 objects. Running rsync: it's faster.
sending incremental file list
./
rsync: failed to set times on "/wx/test/.": Operation not permitted (1)
sent 4267 bytes received 55 bytes 2881.33 bytes/sec total size is 688926 speedup is 159.40
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]
[11:25:57] Rsync exited with code 23, retrying...
[11:25:57] Detected changes in more than 10 objects. Running rsync: it's faster.
*****
Если поставить other — rwx — не помогает
Помогает только если поставить директории owner — fog, но не хотелось бы этого делать, т.к. хотелось бы добавить и других пользователей.
Ну, скрипт можно запустить после того как релиз накачен, если условиями это позволяется. У нас это обычно так. В крайнем случае, как я упоминал выше — ставится мейнтенанс мод и никакие новые записи не появляются. Опять таки в нашем конкретном случае можно себе это позволить. Для тех у кого система вечно живая и её невозможно остановить — ну да, нужно догонять, досинхронизировать. Ну, это уже всё такая теория… что на любой абстрактный вариант можно придумать любую абстрактную проблему, такие вещи нужно придумывать подкладывая к реальному случаю, реальной системе =)
как же с разными constraint-ами (например, not null)
Ну если нул -то понятно в колонках будет нул до релиза, если не нул — обычно ставится default "...".
Иногда при релизе готовится какой-то транзишен/релиз скрипт, который прописывает что-то осмысленное в колонки.
И как, меняя базу, быть уверенными, что это изменение, накаченное отдельно, не сломает существующий код?
Ну новая колонка/таблица точно ничего не сломает, модификация полей происходит редко.
В целом по обоим пунктам — может мы просто не ставим никаких строгих условий, но не помню чтобы с этим были какие-то проблемы.
Сдается мне, что все разрешенные изменения в структуре БД при этой схеме сводятся к 2 операциям
Ну да, или nullable или дефолт, если это подходит.
Опять таки, в любом случае, если релиз откачен и задеплоен заново — можно прогнать скрипт, который проставит значения.
Я думаю, что как всегда — всё зависит от ситуации.
Команда в которой я работаю имеет два основных проекта, один публичный портал, другой внутренний.
Внутренний — гораздо больше. Им пользуются сотрудники компании и мы в принципе берём за основной девиз велосити и готовы к тому, что иногда что-то ломается. Во внутреннем портале у нас больше велосити, меньше QA, во внешнем — больше QA меньше велосити. Поскольку для внутреннего портала релизы зачастую тестируются только разработчиками — то откаты там случаются до пары раз в месяц. Когда сразу — выкатили, опачки, один из сервисов некорректно работает (а мы работаем с десятком внутренних же сервисов) — откатили, другие откатываются через часы после релиза, позже — обычно скрипя зубами фиксим, так как за это время уже другие люди могли накидать своих хотфиксов сверху (не обязательно фиксов, микрорелизов).
Что касается базы, не все релизы связаны с некой записью-чтением БД, иногда она никак не затрагивается и откатывать можно спокойно, есть другие сервисы с которыми мы работаем и при этом в них ничего не пишем или такие сервисы куда пишем но структуру/апи почти никогда не меняем. Поэтому чтобы нужно было откатывать БД такое случается довольно редко. Большинство изменений связанных с БД происходят с добавлением новых полей и таблиц, которые в продакшен ухотят и так за некоторое время до релиза, в котором они нужны и откат можно провести не трогая бд — поля и таблицы так и останутся в проде.
Ну и если всё плохо, конечно откатываем, накатываем определённые таблицы БД обратно.
Реально доставляющие проблемы релизы случаются довольно редко, мы к ним готовимся, делаем бекапы, скрипты отката, ставим портал в мейнтененс мод или рид-онли, релизим, QA прогоняют автоматические тесты и если всё более менее ок тогда открываем портал и т.д.
Если теги не нужны, как потом откатываться, если релиз оказался неудачным?
Точнее до чего откатываться? Для этого релизы фиксируются тегами и в логе прода можно посмотреть в каком порядке релизы попадали в прод и откатиться до предыдущей версии. В нашем случае — одной кнопкой rollback в деплоере.
Не нужно ответвлять что-то от продового бранча
Ну у нас это формальный процесс, поэтому так. На самом деле сделать бранч — дело двух минут. Ишу в багтрекере, новый бранч из id ишу, пишем в него фикс, коммитим, деплоим. При желании даже тут есть место автоматизации, сделать какой-то UI, который будет по нажатию кнопки создавать ишу в багтрекере и бранч из продового тега с нужным именем. Останется только переключиться на него, вписать фикс и запушать/задеплоить.
А зачем ставить всё это по отдельности? По сути просто папки и тестовые домены. Вебсервер работающий в подобном проде енвайрнменте. Синхронизировать заливать продовую базу с дев раз в какое-то время.
Странно, куда как не в отдельный файл/класс вписать тест =)
Я тоже не использую все возможности UnitTest, но в целом их наличие меня не отягощает. :)
Спасибо за ответ.
Всё это китайское барахло как из каменного века — в топку.
Как только оба компьютера оказались на Wi-Fi — синхронизация заработала.
— Генерирую код на одном первом компьютере, даю папку.
— На втором ввожу код и указываю папку.
— На первом в списке Devices появляется запись второго компьютера
— На втором в девайсах первого не видно
— Синхронизация не идёт
Что получается:
Файлы синхронизируются, т.е. по крайней мере попадают в директорию, но в консоли такая ошибка (в цикле):
Если поставить other — rwx — не помогает
Помогает только если поставить директории owner — fog, но не хотелось бы этого делать, т.к. хотелось бы добавить и других пользователей.
Как бы это исправить?
Ну если нул -то понятно в колонках будет нул до релиза, если не нул — обычно ставится default "...".
Иногда при релизе готовится какой-то транзишен/релиз скрипт, который прописывает что-то осмысленное в колонки.
Ну новая колонка/таблица точно ничего не сломает, модификация полей происходит редко.
В целом по обоим пунктам — может мы просто не ставим никаких строгих условий, но не помню чтобы с этим были какие-то проблемы.
Ну да, или nullable или дефолт, если это подходит.
Опять таки, в любом случае, если релиз откачен и задеплоен заново — можно прогнать скрипт, который проставит значения.
Команда в которой я работаю имеет два основных проекта, один публичный портал, другой внутренний.
Внутренний — гораздо больше. Им пользуются сотрудники компании и мы в принципе берём за основной девиз велосити и готовы к тому, что иногда что-то ломается. Во внутреннем портале у нас больше велосити, меньше QA, во внешнем — больше QA меньше велосити. Поскольку для внутреннего портала релизы зачастую тестируются только разработчиками — то откаты там случаются до пары раз в месяц. Когда сразу — выкатили, опачки, один из сервисов некорректно работает (а мы работаем с десятком внутренних же сервисов) — откатили, другие откатываются через часы после релиза, позже — обычно скрипя зубами фиксим, так как за это время уже другие люди могли накидать своих хотфиксов сверху (не обязательно фиксов, микрорелизов).
Что касается базы, не все релизы связаны с некой записью-чтением БД, иногда она никак не затрагивается и откатывать можно спокойно, есть другие сервисы с которыми мы работаем и при этом в них ничего не пишем или такие сервисы куда пишем но структуру/апи почти никогда не меняем. Поэтому чтобы нужно было откатывать БД такое случается довольно редко. Большинство изменений связанных с БД происходят с добавлением новых полей и таблиц, которые в продакшен ухотят и так за некоторое время до релиза, в котором они нужны и откат можно провести не трогая бд — поля и таблицы так и останутся в проде.
Ну и если всё плохо, конечно откатываем, накатываем определённые таблицы БД обратно.
Реально доставляющие проблемы релизы случаются довольно редко, мы к ним готовимся, делаем бекапы, скрипты отката, ставим портал в мейнтененс мод или рид-онли, релизим, QA прогоняют автоматические тесты и если всё более менее ок тогда открываем портал и т.д.
Если теги не нужны, как потом откатываться, если релиз оказался неудачным?
Точнее до чего откатываться? Для этого релизы фиксируются тегами и в логе прода можно посмотреть в каком порядке релизы попадали в прод и откатиться до предыдущей версии. В нашем случае — одной кнопкой rollback в деплоере.
Ну у нас это формальный процесс, поэтому так. На самом деле сделать бранч — дело двух минут. Ишу в багтрекере, новый бранч из id ишу, пишем в него фикс, коммитим, деплоим. При желании даже тут есть место автоматизации, сделать какой-то UI, который будет по нажатию кнопки создавать ишу в багтрекере и бранч из продового тега с нужным именем. Останется только переключиться на него, вписать фикс и запушать/задеплоить.
База на всех одна, как и прочие сервисы.