так и ShellShock и HeartBleed показали что не работает мантра про открытый код= безопасный и много глаз = меньше багов.
Единственное утверждение, которое пока прошло проверку временем — «если на вашей платформе нету вирусов — это означает что в масштабах ботнета вы статистически незаметны, т.е. неинтересны».
Схема холостяка или диванного теоретика.
Если летаешь один — мб она и оптимальна, но тогда весь самолет должен состоять из одиночек. А если летишь с семьей или с группой, ну или сопровождаешь кого-то, кому нужна помощь — эта схема сбоит сильно — до серьезных скандалов.Ну например — на местах 5 и 25 летит ребенок с ДЦП и сопровождающая его мать. И что вы посадите ребенка одного, чтобы он еще сумку закинул наверх?
Для JumpStart будет очень полезно, если вы расскажете в подробностях про Pipeline PoSH, ибо очень важная и большая часть.
И как это все интегрированно с .NET тоже полезно знать (но это уже не совсем фундаментальные основы).
Продолжайте, неплохие материалы в итоге получатся.
ну не то что бы совсем экспертом, можно вполне не программировать под .NET, но успешно пользоваться PoSH. Хотя не отрицаю — знание .NET хорошо помогает, ибо по сути это скриптовый язык для .NET =)
Откуда ж вы, в Microsoft, копируете эту несусветную глупость про то, что Staging окружение надо использовать для тестирования ??? У вас там что где-то есть список официально распространяемых неработающих и идиотских практик?
НЕ используйте staging для тестов, это не только физически «трудно» в силу таких очевидных косяков как отсутствие правильных bindings на сайтах в staging — ваши сайты в staging получают те же bindings что и продакшен, а реальный домен — guid.cloudapp.net, т.е. если у вас binding не *:80\443 — без шаманских плясок вы не достучитесь до своих сайтов в staging слоте.
И заканчивая тем, что при активном стейджинге он у вас будет таскать сообщения из очереди, «тестовый» слот будет писать в продакшен базу, блобы и таблицы. А если вы используете миграции Entity Framework (отдельные грабли) — еще и получите измененую Production базу и с большой вероятностью — P1 Incident в придачу.
Забудьте вы про тестирование в Staging пожалуйста, Staging предназначен для уменьшения времени простоя и гладкого обновления — загрузили новую, оттестированную версию в стейджинг, прогрели, убедились что все инстансы запустились и работают как надо — переключили ее в продакшен, старую остановили.
За все остальные варианты использования Staging — бейте своих разработчиков по рукам стальной линейкой, чтобы неповадно было.
А Microsoft должно быть стыдно, что пишете такие практики.
И еще маленькое имхо — думаю что Cloud Services будут выводиться из обращения — во первых на смену им пришли легковесные websites+webjobs, во-вторых грядет Docker — куда более правильная идея контейнерных приложений.
Так было раньше. И даже это не совсем так — студия все равно загружала в себя движок мсбилда и прогоняла все через его пайплайн, за исключением пары проектов (которые уже морально устарели имхо). Т.е. тогда было 2 хоста для движка — студия и msbuild.exe. Это приводило к тому, что окружение проектов отличалось — студия подсовывала кучу переменных окружения.
Но сейчас это не так — студия, по крайней мере современные ее версии, собирает проекты при помощи честного msbuild.exe, причем можно увидеть отдельные параллельные процессы msbuild.exe запущенные студией с определенными параметрами.
Да, солюшен это не мсбилд скрипт, но его преобразование происходит в msbuild.exe, а не в devenv.exe
В итоге — всё собирается одним и тем же движком, просто вызывается(лся) этот движок из разных врапперов — msbuild.exe и devenv.exe. Теперь один враппер вызывает другой, вместо того чтобы хостить Core engine в себе. Это и есть принципиальная разница?
Да, менталитет. Сам еще тоже не до конца избавился от такого мышления.
На самом деле взгляд на такие вещи как «делиться знаниями» или «сделать хорошо другим» за пределами России довольно сильно отличается от «привычного». Тут принято делиться знаниями (конечно не всеми подряд) потому что это не только поднимает вашу собственную репутацию в сообществе, но и в целом — улучшает само сообщество. Быть умным в компании слабых разработчиков — не интересно. Да, это прям полирует личное эго, но ты все равно понимаешь — один ты не вытянешь проект, а коллеги — ну слабоваты, просто потому что не знают, не умеют и вообще — все делают не так. В итоге — вы круты, они лохи, но проект получается говенный просто потому, что все за ними вы исправить не можете.
А когда подтягиваете их, помогаете — проект в итоге получается классный, ваша репутация потихоньку растет, вас уважают, компания тоже поднимается. Да и вокруг как-то больше умных людей становится — они могут потратить свое время на интересные ништяки (а вы нет — ваше время ограничено) и потом вам рассказать.
Точно также и кодом\знаниями делиться. Вы делитесь — вас замечают, репутация растет, люди про вас слышат и приходят к вам — есть возможность набрать в компанию хороших специалистов, а не остатки на рынке.
Фундаментальное отличие — тут это работает, тут люди ценят репутацию, тебя помнят, делаешь ли ты хорошее или плохое. И да — тут позвонят по всем предоставленным контактам, референсы проверят, репутацию подтвердят. И да — посмотрят ваш код на гитхабе, почитают посты в корпоративных блогах и т.д.
Понятно что всегда есть желание «монетизировать» свой код, более того — тут это проще и легче. Но вот что трудно принять, так это то, что если ты сам чувствуешь что не в силах сам вытянуть\продуктизировать что-то — отдай, поделись, будет лучше всем. Менталитет — «лучше пусть у меня корова сдохнет, но у соседа вдвойне» (не поделюсь но и сам вытянуть не смогу) — реально плох.
Самое лучшее объяснение о том, как именно ( и почему так) работает процессор можно найти в книге «Код. Тайный язык информатики» (Code: The Hidden Language of Computer Hardware and Software) от Чарльза Петцольда.
До этого меня мучали всеми этими схемами в институте — и я это ненавидел. После книги — все понял.
Хмм, ADFS — это сервис для федерации разных Identity Providers между собой, и хотя он вполне неплохо работает в контроллируемой среде — никакие linkedin\facebook\google не будут федерировать свои IdProviders с левыми серверами. Он разве умеет в чистом виде быть STS-RP и объединять что-либо кроме стандартного WS-*\SAML 2.0?
А предложенное решение (вернее Thinktecture Identity Server который выполняет роль STS-RP) — вполне может это все объединить, в итоге можно запилить вполне приличный Single Sign On experience для пользователей аутентифицированных в разных фейсбуках\гугл+\линкединах и прочей OpenId \ OAuth2 братии.
К тому же Thinktecture Identity Server куда более легковеснее ADFS, не говоря уже про то, что ADFS сути прибит намертво к AD, которая однако не бесплатная…
В конце посмотрите на fact checklist — Offline viewing of articles and webpages есть у обоих.
У меня были проблемы с вышеупомянутым Best View, когда сохранялась не статья а ссылка и покет пытался перечитать «актуальную» версию из инета, если статья убрана — прилетал облом. Выключив этот режим — не испытываю проблем с оффлайн чтением даже исчезнувших статей.
Я вообще смутно понимаю в чем суть этого «бэкапа» как фичи, мб это имеется ввиду что сохраняются оригинальные копии и можно увидеть если были изменения. Не очень внятно описанная фича tbh
Вроде все также сохраняет. У него только появился странный режим — best view, который каждый раз перечитывает статью, видать с использованием последнего парсера… т.е. если статью убрали в черновики — она внезапно «выпадает» из покета.
Пожалуйста, не используйте стейджинг окружение для тестов!
Никогда не делайте этого — единственное предназначение стейджинг окружения — более гладкое обновление продакшена (с чем он справляется но средненько).
В остальных случаях вы не просто наступаете на грабли, вы просто бегаете по полю с граблями. Даже сотрудники МС, когда с ними беседуешь на эту тему говорят что изначально они не очень правильно спозиционировали эту фичу. Сейчас они уже не говорят что стейджинг окружение — для тестеров.
Итак краткий перечень самых толстых граблей:
1. Обновление базы в результате миграций (привет от EF) — ваш стейджинг слот может содержать миграции которые несовместимы с тем что в продакшене. Засунули новый пакет, прогрели — получили сломаную базу в продакшене.
2. Vip Swap обратно — возможно. но тоже есть риски. Если вы поломали базу продакшена предыдущим действием — откатиться просто так не получится — вам нужно сделать даунгрейд миграции. А ее то на продакшене еще нету ( потому как она новая и есть только в пакете стейджинга)
3. Несколько сайтов — если у вас несколько сайтов в одной роли (например админка или сайты с разной авторизацией) — работать с ними в стейджинге — невозможно, Hostheader не прописываеся никому кроме основного, т.е. достучаться до админки в стейджинг слоте — нельзя ( это если вы вдруг захотите починить что-то откатом миграции через админку ;) )
4. Очереди. Сделали вы воркер роль, которая при старте начинает таскать сообщения из очереди. Вроде все как МС рекомендовал. Заливаете в стейджинг для тестирования — обнаруживаете что есть бага (ну вы же «тестируете» — это нормально). Ан нет — воркер в стейджинге таскает те же сообщения что и продакше. Ну т.е. из продакшен очереди. Т.е. часть сообщений в очереди было стырено стейджингом, успешно слито по причине бага и кто-то что-то недополучил в продакшене.
Ну и еще много мелких других вещей, за которыми надо следить, если вы действительно хотите иметь контроллируемое продакшен окружение.
Всегда используйте отдельно сконфигурированное тестовое (а можно и девелоперское) окружение. Да это будет дороже, и даже если вы считаете что вырванные на жо..голове волосы отрастут — клиенты попавшие в такие ситуации будут очень обижены на вашу «технологическую платформу».
Wiki
Причем тут помощь CAD вообще?
Единственное утверждение, которое пока прошло проверку временем — «если на вашей платформе нету вирусов — это означает что в масштабах ботнета вы статистически незаметны, т.е. неинтересны».
Если летаешь один — мб она и оптимальна, но тогда весь самолет должен состоять из одиночек. А если летишь с семьей или с группой, ну или сопровождаешь кого-то, кому нужна помощь — эта схема сбоит сильно — до серьезных скандалов.Ну например — на местах 5 и 25 летит ребенок с ДЦП и сопровождающая его мать. И что вы посадите ребенка одного, чтобы он еще сумку закинул наверх?
И как это все интегрированно с .NET тоже полезно знать (но это уже не совсем фундаментальные основы).
Продолжайте, неплохие материалы в итоге получатся.
НЕ используйте staging для тестов, это не только физически «трудно» в силу таких очевидных косяков как отсутствие правильных bindings на сайтах в staging — ваши сайты в staging получают те же bindings что и продакшен, а реальный домен — guid.cloudapp.net, т.е. если у вас binding не *:80\443 — без шаманских плясок вы не достучитесь до своих сайтов в staging слоте.
И заканчивая тем, что при активном стейджинге он у вас будет таскать сообщения из очереди, «тестовый» слот будет писать в продакшен базу, блобы и таблицы. А если вы используете миграции Entity Framework (отдельные грабли) — еще и получите измененую Production базу и с большой вероятностью — P1 Incident в придачу.
Забудьте вы про тестирование в Staging пожалуйста, Staging предназначен для уменьшения времени простоя и гладкого обновления — загрузили новую, оттестированную версию в стейджинг, прогрели, убедились что все инстансы запустились и работают как надо — переключили ее в продакшен, старую остановили.
За все остальные варианты использования Staging — бейте своих разработчиков по рукам стальной линейкой, чтобы неповадно было.
А Microsoft должно быть стыдно, что пишете такие практики.
И еще маленькое имхо — думаю что Cloud Services будут выводиться из обращения — во первых на смену им пришли легковесные websites+webjobs, во-вторых грядет Docker — куда более правильная идея контейнерных приложений.
Но сейчас это не так — студия, по крайней мере современные ее версии, собирает проекты при помощи честного msbuild.exe, причем можно увидеть отдельные параллельные процессы msbuild.exe запущенные студией с определенными параметрами.
Да, солюшен это не мсбилд скрипт, но его преобразование происходит в msbuild.exe, а не в devenv.exe
В итоге — всё собирается одним и тем же движком, просто вызывается(лся) этот движок из разных врапперов — msbuild.exe и devenv.exe. Теперь один враппер вызывает другой, вместо того чтобы хостить Core engine в себе. Это и есть принципиальная разница?
PS: Господа минусующие, зачем портите дискуссию?
За исключением нескольких проектов, студия для сборки не нужна, но возможно не все разработчики это знают.
На самом деле взгляд на такие вещи как «делиться знаниями» или «сделать хорошо другим» за пределами России довольно сильно отличается от «привычного». Тут принято делиться знаниями (конечно не всеми подряд) потому что это не только поднимает вашу собственную репутацию в сообществе, но и в целом — улучшает само сообщество. Быть умным в компании слабых разработчиков — не интересно. Да, это прям полирует личное эго, но ты все равно понимаешь — один ты не вытянешь проект, а коллеги — ну слабоваты, просто потому что не знают, не умеют и вообще — все делают не так. В итоге — вы круты, они лохи, но проект получается говенный просто потому, что все за ними вы исправить не можете.
А когда подтягиваете их, помогаете — проект в итоге получается классный, ваша репутация потихоньку растет, вас уважают, компания тоже поднимается. Да и вокруг как-то больше умных людей становится — они могут потратить свое время на интересные ништяки (а вы нет — ваше время ограничено) и потом вам рассказать.
Точно также и кодом\знаниями делиться. Вы делитесь — вас замечают, репутация растет, люди про вас слышат и приходят к вам — есть возможность набрать в компанию хороших специалистов, а не остатки на рынке.
Фундаментальное отличие — тут это работает, тут люди ценят репутацию, тебя помнят, делаешь ли ты хорошее или плохое. И да — тут позвонят по всем предоставленным контактам, референсы проверят, репутацию подтвердят. И да — посмотрят ваш код на гитхабе, почитают посты в корпоративных блогах и т.д.
Понятно что всегда есть желание «монетизировать» свой код, более того — тут это проще и легче. Но вот что трудно принять, так это то, что если ты сам чувствуешь что не в силах сам вытянуть\продуктизировать что-то — отдай, поделись, будет лучше всем. Менталитет — «лучше пусть у меня корова сдохнет, но у соседа вдвойне» (не поделюсь но и сам вытянуть не смогу) — реально плох.
До этого меня мучали всеми этими схемами в институте — и я это ненавидел. После книги — все понял.
И кстати переведена она достаточно качественно.
Windows 0011 — и нумераци не прерывается и олдскульно — многие оценят.
А предложенное решение (вернее Thinktecture Identity Server который выполняет роль STS-RP) — вполне может это все объединить, в итоге можно запилить вполне приличный Single Sign On experience для пользователей аутентифицированных в разных фейсбуках\гугл+\линкединах и прочей OpenId \ OAuth2 братии.
К тому же Thinktecture Identity Server куда более легковеснее ADFS, не говоря уже про то, что ADFS сути прибит намертво к AD, которая однако не бесплатная…
У меня были проблемы с вышеупомянутым Best View, когда сохранялась не статья а ссылка и покет пытался перечитать «актуальную» версию из инета, если статья убрана — прилетал облом. Выключив этот режим — не испытываю проблем с оффлайн чтением даже исчезнувших статей.
Я вообще смутно понимаю в чем суть этого «бэкапа» как фичи, мб это имеется ввиду что сохраняются оригинальные копии и можно увидеть если были изменения. Не очень внятно описанная фича tbh
Никогда не делайте этого — единственное предназначение стейджинг окружения — более гладкое обновление продакшена (с чем он справляется но средненько).
В остальных случаях вы не просто наступаете на грабли, вы просто бегаете по полю с граблями. Даже сотрудники МС, когда с ними беседуешь на эту тему говорят что изначально они не очень правильно спозиционировали эту фичу. Сейчас они уже не говорят что стейджинг окружение — для тестеров.
Итак краткий перечень самых толстых граблей:
1. Обновление базы в результате миграций (привет от EF) — ваш стейджинг слот может содержать миграции которые несовместимы с тем что в продакшене. Засунули новый пакет, прогрели — получили сломаную базу в продакшене.
2. Vip Swap обратно — возможно. но тоже есть риски. Если вы поломали базу продакшена предыдущим действием — откатиться просто так не получится — вам нужно сделать даунгрейд миграции. А ее то на продакшене еще нету ( потому как она новая и есть только в пакете стейджинга)
3. Несколько сайтов — если у вас несколько сайтов в одной роли (например админка или сайты с разной авторизацией) — работать с ними в стейджинге — невозможно, Hostheader не прописываеся никому кроме основного, т.е. достучаться до админки в стейджинг слоте — нельзя ( это если вы вдруг захотите починить что-то откатом миграции через админку ;) )
4. Очереди. Сделали вы воркер роль, которая при старте начинает таскать сообщения из очереди. Вроде все как МС рекомендовал. Заливаете в стейджинг для тестирования — обнаруживаете что есть бага (ну вы же «тестируете» — это нормально). Ан нет — воркер в стейджинге таскает те же сообщения что и продакше. Ну т.е. из продакшен очереди. Т.е. часть сообщений в очереди было стырено стейджингом, успешно слито по причине бага и кто-то что-то недополучил в продакшене.
Ну и еще много мелких других вещей, за которыми надо следить, если вы действительно хотите иметь контроллируемое продакшен окружение.
Всегда используйте отдельно сконфигурированное тестовое (а можно и девелоперское) окружение. Да это будет дороже, и даже если вы считаете что вырванные на
жо..голове волосы отрастут — клиенты попавшие в такие ситуации будут очень обижены на вашу «технологическую платформу».