Так повелось, что разработчики, еще только начинающие знакомиться с Go, часто сталкиваются с проблемой выбора рабочей директории для Go-проектов. Вот и в чате конференции GolangConf тоже задавался этот вопрос. Новые гоферы часто пугают друг друга словами GOPATH и GOROOT. Однако, в руководствах по быстрому старту с текущей версией Go (1.13) упоминания эти двух «страшных» слов вообще нет.
Рубрика «управление зависимостями»
Правда ли, что GOPATH и GOROOT больше не нужны?
2019-09-17 в 12:47, admin, рубрики: Go, golang, Блог компании Конференции Олега Бунина (Онтико), управление зависимостямиИспользование локальной директории с пакетами в Python уже сейчас
2019-03-20 в 8:26, admin, рубрики: pep, python, импорт модулей, управление зависимостямиВ Python 3.8 предлагается добавить альтернативу виртуальным окружениям — локальную директорию с пакетами PEP 582 Python local packages directory.
Данный PEP предлагает добавить в Python механизм автоматического обнаружения директории __pypackages__ и использовать её при импорте в качестве источника установленных пакетов. Директория __pypackages__ будет иметь больший приоритет при импорте, чем глобальные или пользовательские директории с пакетами. Это позволит исключить создание, активацию или деактивацию виртуальных окружений.
Вот так будет выглядеть в Python 3.8 структура пакета с использованием __pypackages__ :
foo
__pypackages__
3.8
lib
bottle
myscript.pyВ статье я расскажу как использовать локальную директорию с пакетами не дожидаясь выхода Python 3.8.
Наша проблема c зависимостями
2019-03-13 в 16:40, admin, рубрики: Go, open source, абстрагирование зависимости, изоляция зависимости, информационная безопасность, пакетные менеджеры, управление зависимостямиНа протяжении десятилетий повторное использование ПО чаще обсуждалось, чем реально имело место. Сегодня ситуация обратная: разработчики каждый день повторно используют чужие программы, в виде программных зависимостей, а сама проблема остаётся практически неизученной.
Мой собственный опыт включает десятилетие работы с внутренним репозиторием Google, где зависимости установлены как приоритетная концепция, а также разработку системы зависимостей для языка программирования Go.
Зависимости несут серьёзные риски, которые слишком часто упускаются из виду. Переход к простому повторному использованию малейших фрагментов ПО произошёл так быстро, что мы ещё не выработали лучшие практики для эффективного выбора и использования зависимостей. Даже для принятия решения, когда они уместны, а когда нет. Цель этой статьи — оценить риски и стимулировать поиск решений в этой области.
Читать полностью »
Готовим сборку Go-приложения в продакшн
2017-09-05 в 6:35, admin, рубрики: Go, golang, gopath, makefile, сборка приложений, управление зависимостямиВ июне на конференции РИТ++ мы с коллегой Игорем Должиковым делились опытом автоматизации процесса разработки сервисов на Go — от первого коммита и до релиза в продакшн-окружение Kubernetes (да-да, видео начинается с 07:16, и нам тоже это не нравится). С момента публикации мастер-класса время от времени я получаю вопросы по тем или иным темам, затронутым в нем. Пожалуй, самые горячие вопросы достойны отдельного рассмотрения, и сегодня я хотела бы поговорить о процессе сборки приложения. Затрагиваемые темы актуальны не только при подготовке сервисов, но и вообще для любых приложений, написанных на Go.
Всё, что описано в этой статье, актуально для текущей версии Go — 1.9.
Читать полностью »
3 совета для правильного управления зависимостями
2016-10-30 в 15:40, admin, рубрики: bower, composer, dependencies, dependency manager, npm, YARN, Программирование, управление зависимостямиОбновление зависимостей может стать нетривиальной задачей, особенно на проектах, которые существуют долгое время. В этой статье будут приведены советы как остаться up-to-date и сделать обновление как можно более безболезненным.
Управление зависимостями в сложной Agile-среде
2014-10-14 в 6:34, admin, рубрики: agile, scrum, управление зависимостями, управление проектами, управление проектами и командойПеревод статьи «Dependency Management in a Large Agile Environment».
Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.
1 Введение
В октябре 2006 года начался грандиозный переход отдела разработки (R&D) salesforce.com от модели водопада к гибким методологиям, основанных на Scrum. На тот момент прошло 10 месяцев с предыдущего мажорного релиза, а дата выпуска нового переносилась уже пять раз. Многих расстраивало, что продукт выпускается редко и с серьёзными опозданиями. Мы не стали дожидаться завершения релиза, реорганизовали существующие команды в Scrum-команды и с помощью процессов Scrum выпустили релиз в феврале 2007 года. С тех пор, используя наш новый гибкий подход, мы выпустили уже пять мажорных релизов (длительностью в 3-4 месяца) нашего набора SaaS приложений и платформы Force.com. Каждый из них состоялся точно в запланированный день.
Во время реорганизации мы следовали рекомендациям Scrum для отдельных команд, но не обращали особого внимания на взаимодействие между командами. Формируя команды, мы стремились минимизировать зависимости между ними, однако код не изменился в одночасье, так что сохранилось немало взаимосвязей. Довольно скоро мы внедрили Scrum-of-Scrum meetings. Эти встречи помогали обсуждать проблемы и состояние дел, но одних только собраний было недостаточно. Работая над последними пятью релизами, мы опробовали и отшлифовали дополнительные подходы, улучшающие взаимодействие команд. Далее в статье мы расскажем о некоторых трудностях с управлением зависимостями и о том, как мы преодолели эти проблемы.
Читать полностью »