{
"name": "testts",
"version": "1.0.0",
"description": "",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"build": "tsc && ./utils/iconv.sh"
},
"author": "",
"license": "ISC",
"devDependencies": {
"typescript": "^4.6.3"
}
}# !/bin/sh
cd dist
rm -rf *.1251.js
find . -type f -name '*.js' -o -name '*.1251.js' | while read i
do
echo $i
iconv -f UTF-8 -t WINDOWS-1251 "$i" > tmp
mv -f tmp "$i"
done
cd ..
0. архитектор дизайнит весь проект и определяет что где как и на чем будет сделано
1. дизайнер рисует картинку (есть еще UI дизайнер, он не только картинку но и последовательность действий определяет)
2. верстальщик борется с css и html, бодаясь с разным железом и браузерами, по факту он делает статичные странички или их части
3. фронтэндер оживляет сайт, используя уже готовый html код от верстальщика
кстати этот этап можно опустить, если у вас чистая server side генерация страниц, тогда фронтэндер фактически будет совмещать свою должность с бакэндером
4. бакэндер реализует бизнес логику работы приложения на серверной стороне
иногда этот этап можно сильно оптимизировать, превратив бакэнд в прослойку базы данных, но тогда либо разработчик базы данных будет реализовывать бизнес логику (выворачивая мозги не подходящим инструментом), либо фронтэндер (создавая кучу уязвимостей)
5. разработчик баз данных создает правильно базу такой, чтобы она не укладывала сервер десятком клиентов
в простых случаях бакэндер может и сам справиться, но простые случаи таковыми надолго не остаются
6. devops администратор настраивает все великолепие, пилит скрипты авторазвертывания, бакапы, мониторинг,...
jenkins-development
Правило такое есть 3 ветки prod, stage,dev
в дженкинсе есть 3 задачи каждая вытаскивает соответствующую ветку из гита, дальше откомментирую в коде
yanotes.auth.service-Dev