chupasaurus, хорошо. Давайте по другому. Опишите процесс автодеплоя веб-приложения, а я возьму на вооружение.
Дано: Десятки разработчиков, каждый работает в своей ветке, но при попадании в мастер должен произойти автоматический деплой (~50раз в сутки). Изменения происходят одновременно в коде, в шаблоне или json-файле, изображении. Размер проекта 400mb.
chupasaurus, Еще немаловажный фактор, присутствие дополнительных файлов в сорцах. Условно - шаблоны, css, изображения и т.д. Которые в экзешник попросту не попадут, а в процессе разработки эти файлы могут в любой момент измениться и должны быть обновлены на сервере.
chupasaurus, да точно, выше был разговор об SDK на сервере, потому так и написал.
В моем случае смысл в том, что в день множество мелких коммитов в десятки-сотни байт. На сервере с gitlab выполняются CI перед попаданием кода в мастерветку. А дальше по вебхуку сервер подтягивает с гита десяток байт изменений и собирает бинарник.
chupasaurus, это вопрос удобства в каждом конкретном случае. Из разряда "бороду на одеяло ложить или под него". У нас настроен деплой из сорцов и все преотлично работает, за несколько лет не было никаких проблем. 100-200 метров SDK на сервере кого вообще вообще напрягают?
chupasaurusСтепан И., а зачем для go нужен JDK? Для сборки нужен только golang, который около 100Mb со всеми утилитами и ставится через пакетный менеджер.
switch game {
case "", "football":
log.Print(1)
fallthrough // равносильно отсутствию "break" в реализации в js
case "soccer":
log.Print(2)
case "basketball":
log.Print(3)
}
majetree: ну ту не в вариантах дело, наблюдал ровно неделю назад такую картину, когда установка неправильно работала. Из-за "$GOPATH/bin" - в результат попадала строка типа "/path/1:/path/2/bin"
А еще в export PATH= кроме $GOROOT можно добавить $GOBIN чтобы программы, установленные через go install не приходилось запускать с указанием полного пути.
Замечу только, что юзать export GOBIN="$GOPATH/bin" не совсем верно. $GOPATH как и $PATH может содержать несколько путей разделенных двоеточием. Если в нем прописано так: /home/user/.go:/home/user/work то внешние пакеты через go get устанавливаются в .go, а свои лежат в в work и все отлично работает. Ну кроме GOBIN="$GOPATH/bin".
rustler2000: чтобы под любой платформой сбилдить бинарники под все платформы? Ведь под текущую и так все собирается по go build, не? Почему спросил - вот уже от многих слышал, make, make. А мы юзаем go get ./...; go build и я решил, что есть сакральный смысл создавать мейк-файл
Проблема в человеческом факторе. Понятно, что можно написать в README, чтобы админы и девелоперы ложили пакет в $GOPATH/src, но тогда кто-нибудь додумается переименовать каталог, и т.д. Идем дальше - возникает необходимость форкнуть проект, который использует свои подпакеты. Но в import секциях останутся подпакеты старого репозитория, и большой шанс, что в результате правок исходного проекта может сломаться форк. Идеальным вариантом было бы что-то типа import "$SELF/subpackage", но такого, к сожалению нет, как я понимаю..
beduin01: с dlang я знаком вобщем-то, изучал около недели, признаюсь, не осилил в достаточной мере для решения поставленной задачи. Так-как время поджимало решил обратится к go, который мне посоветовали. И на следущий день было готово решение, которое до сих пор крутится на продакшине. И вобщем я периодически посматриваю на D, возможно когда-то еще к нему приду. Хотя те примеры, которые я вижу, навевают тоску. Возможно это некоторое сходство с кодом, с которым приходилось работать много лет - js. Возможно я просто уже слишком стар, чтобы держать весь спектр инструментов языка в голове. Хочется просто сконцентрироваться на архитектуре приложения, а не рыться в документации, чтобы понять, а каким способом решать данную конкретную мелочевку.
beduin01: оу, я имел в виду задачу выше. Но в целом суть программирования на D теперь я понял, можно делать всю программу в строку, и просто купить мышку с горизонтальным скроллом. В целом удобно.
beduin01: ы..., ну если он такой простой, то в чем была проблема переделать пример? Ну да и ладно. Я ведь не об D говорил, а вообще об однострочниках. Я прекрасно понимаю, что такое решать подобные задачи одной строкой. В том же js я и не такие штуки проделывал одной строчкой. Это прикольно, когда в целом кроме этой строчки ничего и не нужно. А когда проект 100K строк, то это полная *опа. Никакой читаемости там и в помине нет. Каждый кодер городит на что горазд, и сходу бывает хрен разберешься, что вообще делает эта строка.
