Быстрое развёртывание окружений предлагали ребята teatro, упомянутые в описании gitlab flow, но похоже они пропали куда-то. И как вариант, telepresence.io — локально работающее приложение как-будто работает в удалённом кластере, но ещё не пробовали.
Лок файлов похоже доступен только EE пользователям. .gitlab-ci.yml в отдельной ветке создаст пайплайн только для этой ветки. В двух словах: про безопасность gitlab ci есть несколько задач и возможно будет даже какое-то стандартное решение, но пока мы сделали свой патч, про это будет в следующей части.
when не подходит тем, что on_failure/on_success работает только для автоматических задач и то, только в момент, когда создаётся пайплайн. Если автоматическая задача упадёт, то следующие не запустятся, но даже, если поправить проблему и перезапустить упавшую задачу, то следующие за ней не пойдут в работу. Нам это не слишком мешает, больше мешает, что ручные задачи можно запустить когда угодно. Подробнее про все эти ограничения опять же в следующей части.
Про опциональное выполнение задач скажу так:
У нас такой потребности не возникает, потому что фронт и бэк в разных репозиториях и вообще можно сказать микросервисность, когда один фронт использует API нескольких бэков.
В статье упомянуто, что для сборки используем dapp. В вашем сценарии, когда фронт и бэк в одном репозитории, при правильно написанном Dappfile, образ фронта не будет собираться автоматически, если изменения только в исходниках бекенда.
Как вариант вместо git log можно попробовать файлы-флаги. Скрипт сборки будет проверять, скажем, что в корне репозитория есть .do-not-build-front и не запускать сборку фронта. На следующей стадии можно будет не запускать тесты для фронта. В следующей части будет с примерами, как использовать похожие файлы-флаги.
Вообще проблема условного выполнения пайплайна нами тоже ощущается, но пока что хватает названий веток/тэгов. Однако этого всё равно мало, очень хочется иметь возможность перезапустить билд с другими параметрами.
В общем хороший вопрос-то, за что минусы? Статья же висит в хабе разработки.
Про цикл разработки уже были комментарии от коллег вот в этом треде: https://habrahabr.ru/company/flant/blog/331188/#comment_10274996
С точки зрения devops-инженера всё живёт именно в gitlab — коммит в infra_*, пуш в git, выкат в своё окружение, проверка.
С точки зрения разработчика push в feature_* происходит, когда фича готова к интеграционному тестированию. То, что можно прогнать локально на среднем железе и быстро — то лучше делать локально, ведь не каждую строчку кода надо тестировать селениумом? В каждом проекте нужно приходить к некоему компромиссу — что запускать локально, какие сервисы локально разворачивать, а что проще пушнуть и потом смотреть логи в gitlab-е.
То есть часть #0 ещё более индивидуальна, чем части #1 и #2. Но тема конечно актуальная, тут сложно спорить, рано или поздно тоже статью напишем.
P.S. Есть ещё один вариант, который снимет вопросы про тесты и развёртывание окружения на локальной машине разработчика — применение web IDE.
Ну и представлять, что стрелочки можно рисовать в существенно большем количестве размерностей, нежели 2 или 3.
На пальцах скалярное произведение можно представлять как меру того, насколько один вектор похож на другой.
Секундный сэмпл — это вектор размерностью 44100.
Попробую соорудить аналогию для иллюстрации процесса:
Пусть есть две строки с пробелами и словом где-то между пробелами (пробелы ест парсер, пусть будет минус), например, s1 = "----------Slovo---"
s2 = "-------Slovo------"
Теперь примем, что строки s1 и s2 — это вектора размерностью 18, а значения координат это ASCII коды символов. Дальше из s2 получим 18 векторов с помощью циклического сдвига: s [0] = "-------Slovo------"
s [1] = "--------Slovo-----"
s [2] = "---------Slovo----"
s [3] = "----------Slovo---"
s [4] = "-----------Slovo--"
...
s [8] = "vo-------------Slo"
...
s[17] = "------Slovo-------"
s[18] = "-------Slovo------" == s[0]
Теперь остаётся подсчитать 18 раз скалярное произведение строки s1 с каждым из полученных векторов и запомнить тот вектор и его индекс, где будет наибольшее скалярное произведение. Полученный индекс будет сдвигом «Slovo» в строке s2 относительно строки s1.
Для массового производства слишком сложно. Хим процессы в больших ваннах проще и дешевле.
А для хобби есть вот такой проект печаталки проводящими чернилами (и как бонус — тот же станок может сверлить и наносить надписи): www.kickstarter.com/projects/voltera/voltera-your-circuit-board-prototyping-machine
Эх, вот бы они на годик раньше компанию стартанули, а не в начале 2015, когда $1200 оказались конским ценником даже для хобби, на которое вроде как ничего не жалко ;]
Именно с дефисом, без ё и в мужском роде с намёком, что это не «организация» и не «государство», а какое-то нарицательное слово обозначающее террористов (смори, смори, опять игилов по телику кажут). =)
Однозначного ответа на вопрос безболезненной смены флэшки нет. У айфона ведь наоборот: он изначально умеет общаться с памятью объёмом 128Гб.
Ваш плеер может быть разработан под 8Гб микросхему с определённым протоколом, и версии микросхемы с таким же протоколом, но на 16Гб может и не быть. Или есть, но дополнительный бит адреса надо передавать немного по-другому, а прошивка этого не умеет. С другой стороны, вот модель E585 — в ней 16Gb, с большой долей вероятности эти модели сделаны на основе одной платы, тут надо узнать, какая флэшка в E585 и перепаять.
Быстрое развёртывание окружений предлагали ребята teatro, упомянутые в описании gitlab flow, но похоже они пропали куда-то. И как вариант, telepresence.io — локально работающее приложение как-будто работает в удалённом кластере, но ещё не пробовали.
Лок файлов похоже доступен только EE пользователям. .gitlab-ci.yml в отдельной ветке создаст пайплайн только для этой ветки. В двух словах: про безопасность gitlab ci есть несколько задач и возможно будет даже какое-то стандартное решение, но пока мы сделали свой патч, про это будет в следующей части.
when не подходит тем, что on_failure/on_success работает только для автоматических задач и то, только в момент, когда создаётся пайплайн. Если автоматическая задача упадёт, то следующие не запустятся, но даже, если поправить проблему и перезапустить упавшую задачу, то следующие за ней не пойдут в работу. Нам это не слишком мешает, больше мешает, что ручные задачи можно запустить когда угодно. Подробнее про все эти ограничения опять же в следующей части.
Про опциональное выполнение задач скажу так:
Про цикл разработки уже были комментарии от коллег вот в этом треде: https://habrahabr.ru/company/flant/blog/331188/#comment_10274996
С точки зрения devops-инженера всё живёт именно в gitlab — коммит в infra_*, пуш в git, выкат в своё окружение, проверка.
С точки зрения разработчика push в feature_* происходит, когда фича готова к интеграционному тестированию. То, что можно прогнать локально на среднем железе и быстро — то лучше делать локально, ведь не каждую строчку кода надо тестировать селениумом? В каждом проекте нужно приходить к некоему компромиссу — что запускать локально, какие сервисы локально разворачивать, а что проще пушнуть и потом смотреть логи в gitlab-е.
То есть часть #0 ещё более индивидуальна, чем части #1 и #2. Но тема конечно актуальная, тут сложно спорить, рано или поздно тоже статью напишем.
P.S. Есть ещё один вариант, который снимет вопросы про тесты и развёртывание окружения на локальной машине разработчика — применение web IDE.
Секундный сэмпл — это вектор размерностью 44100.
Попробую соорудить аналогию для иллюстрации процесса:
Пусть есть две строки с пробелами и словом где-то между пробелами (пробелы ест парсер, пусть будет минус), например,
s1 = "----------Slovo---"
s2 = "-------Slovo------"
Теперь примем, что строки s1 и s2 — это вектора размерностью 18, а значения координат это ASCII коды символов. Дальше из s2 получим 18 векторов с помощью циклического сдвига:
s [0] = "-------Slovo------"
s [1] = "--------Slovo-----"
s [2] = "---------Slovo----"
s [3] = "----------Slovo---"
s [4] = "-----------Slovo--"
...
s [8] = "vo-------------Slo"
...
s[17] = "------Slovo-------"
s[18] = "-------Slovo------" == s[0]
Теперь остаётся подсчитать 18 раз скалярное произведение строки s1 с каждым из полученных векторов и запомнить тот вектор и его индекс, где будет наибольшее скалярное произведение. Полученный индекс будет сдвигом «Slovo» в строке s2 относительно строки s1.
W.Schwarze получил значение 338,6⋅10-6 кал/см⋅сек⋅град при 0°С что в СИ примерно равно 0,1418 Вт/м⋅К и примерно соответствует современному значению. Теплопроводность воздуха принималась тогда 58,3⋅10-6 кал/см⋅сек⋅град при 0°С.
А для хобби есть вот такой проект печаталки проводящими чернилами (и как бонус — тот же станок может сверлить и наносить надписи): www.kickstarter.com/projects/voltera/voltera-your-circuit-board-prototyping-machine
Эх, вот бы они на годик раньше компанию стартанули, а не в начале 2015, когда $1200 оказались конским ценником даже для хобби, на которое вроде как ничего не жалко ;]
А можете привести примеры вопросов, которые задают уже не junior, а senior-ам на собеседованиях? Чтобы было куда стремиться дальше.
Ваш плеер может быть разработан под 8Гб микросхему с определённым протоколом, и версии микросхемы с таким же протоколом, но на 16Гб может и не быть. Или есть, но дополнительный бит адреса надо передавать немного по-другому, а прошивка этого не умеет. С другой стороны, вот модель E585 — в ней 16Gb, с большой долей вероятности эти модели сделаны на основе одной платы, тут надо узнать, какая флэшка в E585 и перепаять.