5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
клиентов больше 20 штук? Порядок хотя бы. 3, 5-10, 20+?
есть из них какие-то кто «на всем последнем/свежем/актуальном» сидит?
цикл релизный общий или каждый в свое время, независмо от остальных?
когда тебе для нескольких клиентов нужны разные версии продукта, например?
Читать полностью…
у каждой релизной ветки для тестирования будет создаваться своя инфра?
Читать полностью…
в кейсе «основное в транке» почти не отличается от предыдущего, вместо 2 стабильных веток будет 2+N, где N это сколько старья таскаете
в эти допветки идет обычно бэкпорт и фиксы только, если всегда начинать с мастера (не разрабатывать фичи с 0 в легаси-ветках) - ведение может быть даже надежным
Самое тупое и просто в вашем случае, это ввести релизные ветки
В таком случае ваша тест ветка соответствует develop ветке, прод ветка - мэйн/мастер ветке в Gitflow
Посмотри про паттерны ведения а git, а так работал с:
+ Релизная ветка для тестирования, мастер для прода
+ просто ветка фича и релизная
На дев стенд можно выкатывать чисто одну ветку (не обязательно связанную с фичей)
Про транк тоже мысль интересная
если фича нужна срочно в проде - ихначально делаем фичу от прод ветки, а потом сливаем и туда и сюда
Читать полностью…
Переходите на транк бэйзд девелопмент, и выкиньте ветки🌚
Читать полностью…
Привет всем!
Как организовать процесс разработки, если у нас есть следующие ветки: test, prod, а также feature-ветки для каждого разработчика, с учетом следующих требований и проблем:
Текущая структура:
Ветка test используется для тестирования новых фич.
Ветка prod содержит код, готовый для продакшена.
Каждый разработчик создает свою feature-ветку (например, feature/feature-name) для разработки новой функциональности.
Проблемы:
Иногда необходимо протестировать одну фичу на test и выпустить её в prod, но при этом другая фича, находящаяся на test, не должна быть выпущена.
Текущая структура веток затрудняет изолированное тестирование функционала отдельных разработчиков.
Нет способа протестировать конкретные изменения разработчика в изолированной среде, чтобы другие фичи не мешали.
Вопрос:
Какой подход к управлению ветками и средами (например, персональные dev-ветки, отдельные среды для feature-веток) можно использовать, чтобы решить эти проблемы и упростить процесс разработки, тестирования и релиза?
Мой кейс касался не именно .ogg, каких-то других форматов (.aiff и чего-то iOS-ного), но в целом решение поди тоже самое.
Мы за какое-то разумное время поняли, что на джаве этого не сделать, и пошли другим путём. Просто берёшь node.js и пилишь небольшой сервис одностраничник на нём =)
У нас fastify как сервер и music-metadata для извлечения данных из аудио.
эт то понятно, ищется именно сдк от самих свифтов (https://docs.developer.swift.com/docs/developer-tools/swift-sdk/downloads)
Читать полностью…
https://github.com/prowide/prowide-core
вроде эту использовали
Добрый день, я так понимаю здесь все гуру программирования? Не подскажите, если ли чаты для новичков совсем зеленых по Java?
Читать полностью…
Для тестирования релизов обычно staging окружение используют
Читать полностью…
но вообще бэкпорт конечно добавляет боли и требований к команде, а без требований/дисциплины этой боли очень много
Читать полностью…
Тогда легко через релизные ветки и коммит в мастер через тэг катить отдельно фичи
Читать полностью…
Большое спасибо за ответ. А почему приняли решение что на java это не сделать?
Читать полностью…
Кроме шуток, на мой взгляд в этом подходе намного проще разрабатывать, но нужно иметь определённую культуру, чтобы мастер (транк) всегда был зелёным и не падал. Нужно покрывать код тестами, уметь в гибкие фича флаги
Читать полностью…
Я когда-то работал в проекте, где были схожие требования. Сделали так:
1. master - то, что льётся в прод (через создание тега)
2. stage - то, что тестируется в совокупности с другими задачами перед продакшеном. Для stage поднимается изолированное окружение, которое ковыряют тестеры. Если что-то отсюда надо откатить, то через revert-коммит
3. feature-ветки. Создаются под каждую задачу. Так же, как и в случае stage, можно было поднять изолированное окружение (с другими feature-окружениями или stage они не связаны). За уничтожением этих окружений надо следить. Старые выпиливались как-то автоматически, но их можно было при желании вновь поднять
Соответственно QA тестят feature-ветки. Если всё ок, то дают добро. Перед релизом мержи feature-веток в stage приостанавливаются, QA тестят stage. После этого либо принимаются решения по фиксам, либо релиз
Есть "универсальный комбайн" ffmpeg. Возможно, поможет. Можно запускать из Java-кода как приложение ОС, получать его вывод в виде строки и парсить.
Читать полностью…
Здравствуйте. Задача узнать длительность ogg opus файла. Библиотеки с ogg файлом почему то не работают. Подскажите, сталкивался ли кто нибудь с подобной задачей? Какими библиотеками пользовались?
Читать полностью…
а я уж подумал про свифт сдк эппл для платежей (у них есть)
Читать полностью…