підхід?
Коли ти будеш усе дробити ти заманаєшмя залежності контрольювати.
Так, це ж називається монорепозиторій. Але є декілька дуже важливих моментів: 1. CI/CD ускладнюється; 2. Треба ДУЖЕ сильно контролювати, що і де кладеж, аби не заплутатися; 3. Довше викачувати, більше і тд, але це не критично...
Я просто не працював з мікросервісами і от думаю як правильно організувати саме код, тому що тоді на кожен свій контекст, на кожен своя база і код повторюється
Правильно - ніяк) Роби так як тобі і твоїй команді(ам) буде зручніше девелопити Якшо через Х часу не захочете змінити підхід - знач от він правильний солюшн)
Ну я зараз пишу диплом на мікросервісах - і у мене воно зараз всередині гітхаб орги, але я не схиляю до цього підходу, бо тут свої + та -
> CI/CD ускладнюється; Треба слідкувати за підпапками і регулювати на що тригеритись, це так. Але зазвичай такі фільтри у багатьох CI/CD не проблема налаштувати > Треба ДУЖЕ сильно контролювати, що і де кладеж, аби не заплутатися; True, але це додатково б'є по рукам і примушує вибодувати пенву структуру. Це потім сильно допомагає при навігації > Довше викачувати, більше і тд, але це не критично Це стає боляче якщо в тебе під 1к девелоперів пишуть код в одному репу) Якраз на днях відкрив для себе https://git-scm.com/docs/scalar https://devblogs.microsoft.com/devops/introducing-scalar/ https://github.blog/2022-10-13-the-story-of-scalar/ Щоб зменшити кількість мігреней через це
Так, 100% те що ти написав - правильно. З 3м пунктом особисто зіштовхувався і то страшно. А інше - не проблеми, а моменти на які просто тре звернути увагу. Для мене зараз зручніше бахнути оргу і пиляти прості репки на 100-150 файлів
Але це зручно бо я 1, і ніхто не заважає розважатися з тим, як я захочу
Я б заїбався це менеджити. Всі мої пети майже завжди монорєпи
Ахаххаха
владік глянь лс 🙃
Оплату натурою не приймаю, лише в шекелях :)
Саме ртуть навчила працювати із Гітом
Обсуждают сегодня