Raporda bazı DevOps uygulamalarından bahsedilecek ancak geliştiricinin bakış açısıyla. Tipik olarak DevOps'a katılan tüm mühendislerin zaten birkaç yıllık idari deneyimi vardır. Ancak bu, geliştiriciye burada yer olmadığı anlamına gelmiyor. Çoğu zaman geliştiriciler "günün bir sonraki acil kritik hatasını" düzeltmekle meşguller ve DevOps alanına hızlıca göz atmaya bile zamanları olmuyor. Yazarın anlayışına göre DevOps her şeyden önce sağduyudur. İkincisi, daha etkili olma fırsatıdır. Bir geliştiriciyseniz, sağduyuluysanız ve bir takım oyuncusu olarak daha etkili olmak istiyorsanız bu rapor tam size göre.
Представлюсь, я вполне допускаю, что в зале есть люди, которые меня не знают. Зовут меня Антон Бойко, я являюсь Microsoft Azure MVP. Что такое MVP? Это Model-View-Presenter. Model-View-Presenter – это именно я.
Ayrıca şu anda Ciklum'da çözüm mimarı olarak görev yapıyorum. Yakın zamanda kendime çok güzel bir alan adı satın aldım ve genellikle sunumlarda gösterdiğim e-posta adresimi güncelledim. Bana şu adresten yazabilirsiniz: me [dog] byokoant.pro. Sorularınız için bana e-posta gönderebilirsiniz. Genelde onlara cevap veriyorum. Tek şey şu ki e-postayla iki konuyla ilgili sorular almak istemiyorum: siyaset ve din. Diğer her konuda bana e-posta yoluyla yazabilirsiniz. Biraz zaman geçecek, cevap vereceğim.
Kendin hakkında birkaç kelime:
- 10 yıldır bu alandayım.
- Microsoft'ta çalıştım.
- Я отец-основатель украинского Azure-сообщества, которое мы основали где-то в 2014-ом году. И до сих пор оно у нас есть и развивается.
- Я также отец основатель Azure-конференции, которая у нас проходит в Украине.
- Также я помогаю организовать Global Azure Bootcamp в Киеве.
- Как я уже сказал, я – Microsoft Azure MVP.
- Sık sık konferanslarda konuşuyorum. Konferanslarda konuşmayı gerçekten seviyorum. Geçen yıl yaklaşık 40 kez sahneye çıktım. Ukrayna, Beyaz Rusya, Polonya, Bulgaristan, İsveç, Danimarka, Hollanda, İspanya'dan geçerseniz veya Avrupa'da başka bir ülkeye verir veya alırsanız, akışında bulut teması olan bir konferansa gittiğinizde, beni konuşmacılar listesinde görebilirsiniz.
- Ben de bir Star Trek hayranıyım.
Biraz Gündemden bahsedelim. Gündemimiz çok basit:
- Мы поговорим, что такое DevOps. Поговорим, почему это важно. Раньше DevOps – это было ключевое слово, которое вы писали в резюме и получали сразу +500 долларов к зарплате. Сейчас нужно писать, например, blockchain в резюме, чтобы получить +500 долларов к зарплате.
- Daha sonra bunun ne olduğunu biraz anladığımızda DevOps uygulamalarının ne olduğundan bahsedeceğiz. Ancak genel olarak DevOps bağlamında değil, geliştiricilerin ilgisini çekebilecek DevOps uygulamaları hakkında. Bunların neden ilginizi çekebileceğini size anlatacağım. Size bunu neden yapmanız gerektiğini ve bunun daha az acı çekmenize nasıl yardımcı olabileceğini anlatacağım.
Традиционная картинка, которые показывают многие. Это то, что происходит во многих проектах. Это когда у нас есть отделы разработки и operations, которые поддерживают наш софт. И эти отделы между собой не общаются.
Возможно, если вы не настолько ярко смогли прочувствовать именно на отделах DevOps и operations, вы можете провести аналогию с отделами Dev и QA. Есть люди, которые разрабатывают софт и есть QA, которые плохие с точки зрения разработчиков. Например, я коммичу в репозиторий свой прекрасный код, а там сидит какой-то негодяй, который мне этот код возвращает и говорит, что ваш код плохой.
Это все происходит по той причине, что люди между собой не общаются. И они через какую-то стену недопонимания перекидывают друг другу какие-то пакеты, какое-то приложение и пытаются что-то с ними с делать.
Как раз разрушить эту стену и призвана DevOps-культура, т.е. заставить людей между собой общаться и хотя бы понимать, чем вообще занимаются разные люди в проекте и почему их работа важна.
И когда мы говорим про DevOps, то кто-то вам скажет, что DevOps – это когда в проекте есть continuous integration; кто-то скажет, что DevOps – это если в проекте реализована практика "инфраструктура как код"; кто-то скажет, что первый шаг к DevOps – это feature branching, feature flags.
По сути, это все по-своему правда. Но это всего лишь конечные практики, которые у нас есть. Перед тем, как переходить к этим практикам, я предлагаю посмотреть на этот слайд, который показывает 3 этапа внедрения Dev-Ops методологии в вашем проекте, в вашей компании.
Bu slaydın ikinci bir resmi olmayan adı da var. DevOps'un 3 Silahşörünün ne olduğunu öğrenmek için internette arama yapabilirsiniz. Bu makaleyi bulmanız mümkündür. Neden 3 Silahşörler? Altında şunu yazıyor: insanlar, süreçler ve ürünler, yani. PPP – Porthos, Porthos ve Porthos. İşte DevOps'un 3 Silahşörleri. Bu makalede bunun neden önemli olduğu ve neleri gerektirdiği daha ayrıntılı olarak açıklanmaktadır.
Когда вы начинаете внедрять DevOps-культуру, очень важно, чтобы она внедрялась в следующем порядке.
Первоначально вам нужно говорить с людьми. И вам нужно объяснить людям, что это такое и как они смогут получить от этого какие-то преимущества.
Конференция у нас называется DotNet Fest. И как мне сказали организаторы, что сюда у нас в основном была приглашена аудитория разработчиков, поэтому я надаюсь, что большинство людей в зале занимаются разработкой.
İnsanlar hakkında konuşacağız, geliştiricilerin her gün ne yapmak istedikleri hakkında konuşacağız. En çok ne istiyorlar? Yeni kodlar yazmak, yeni çıkmış çerçeveler kullanmak, yeni özellikler yaratmak istiyorlar. Geliştiriciler en az neyi istiyor? Eski hataları düzeltin. Umarım benimle aynı fikirdesindir. Geliştiricilerin istediği de bu. Yeni özellikler yazmak istiyorlar, hataları düzeltmek istemiyorlar.
Belirli bir geliştiricinin ürettiği hataların sayısı, kollarının ne kadar düz olduğuna ve bunların popo ceplerinden değil omuzlarından ne kadar büyüdüklerine bağlıdır. Ancak yine de büyük bir projemiz olduğunda bazen her şeyi takip etmek imkansız olabiliyor, bu yüzden daha istikrarlı ve daha kaliteli kod yazmamıza yardımcı olacak bazı yaklaşımları kullanmak bizim için iyi olur.
QA'lar en çok ne istiyor? Salonda olup olmadıklarını bilmiyorum. QA istediğimi söylemek benim için zor çünkü hiçbir zaman QA olmadım. Ve adamlar alınmasın, umarım asla yapmayacağım söylenecek. Ama onların çalışmalarını anlamsız ve işe yaramaz bulduğum için değil, kendimi bu işi verimli bir şekilde yapabilecek biri olarak görmediğim için, yapmaya bile çalışmayacağım. Ancak anladığım kadarıyla, QA'in en çok sevmediği şey sabahları işe gitmek, sürekli olarak bir tür regresyon testi yapmak, geliştiricilere 3 sprint önce bildirdikleri hataların aynısına basmak ve şunu söylemek: "Ne zaman yapacaksın?" , Mösyö D 'Artagnan, bu hatayı düzeltin.' Ve Mösyö D'Artagnan ona cevap veriyor: "Evet, evet, evet, bunu zaten düzelttim." Ve nasıl oldu da bir hatayı düzelttim ve yol boyunca 5 hata yaptım.
Люди, которые занимаются поддержкой этого решения на production, хотят, чтобы это решение работало без багов, чтобы им не приходилось переподнимать сервер каждую пятницу, когда все нормальные люди идут в бар. Разработчики в пятницу задеплоились, админы сидят до субботы, пытаясь этот деплой поднять, починить.
Ve insanlara aynı sorunları çözmeyi hedeflediklerini açıkladığınızda süreçleri resmileştirmeye geçebilirsiniz. Bu çok önemli. Neden? Çünkü “formalizasyon” derken en azından peçete üzerinde bir yerde süreçlerinizin nasıl gerçekleştiğini anlatmanız önemli. Örneğin, bir QA ortamına veya bir üretim ortamına dağıtım yapıyorsanız, bunun her zaman bu sırayla gerçekleştiğini anlamalısınız; bu aşamalarda örneğin otomatik birim testleri ve kullanıcı arayüzü testleri yürütüyoruz. Dağıtımdan sonra dağıtımın iyi mi kötü mü gittiğini kontrol ediyoruz. Ancak üretime dağıttığınızda tekrar tekrar tekrarlanması gereken eylemlerin net bir listesine zaten sahipsiniz.
И только когда у вас процессы формализованы, вы приступаете к выбору продуктов, которые помогут вам вот эти процессы автоматизировать.
Ne yazık ki bunun tersine gerçekleştiğini çok sık görüyorum. Birisi "DevOps" kelimesini duyar duymaz hemen Jenkins'i kurmayı öneriyor çünkü Jenkins'i kurar kurmaz DevOps'a sahip olacaklarına inanıyorlar. Jenkins'i kurdular, Jenkins web sitesindeki "Nasıl yapılır" makalelerini okudular, bu Nasıl yapılır makalelerine süreçleri doldurmaya çalıştılar ve sonra insanların yanına gelip insanları eğdiler ve kitabın bunu bu şekilde yapmanız gerektiğini söylediğini söylediler. yani bunu bu şekilde yapıyoruz.
Jenkins'in kötü bir araç olduğu söylenemez. Bunu hiçbir şekilde söylemek istemiyorum. Ancak bu ürünlerden sadece bir tanesi. Ve hangi ürünü kullanacağınız son kararınız olmalı, hiçbir şekilde ilk kararınız olmamalıdır. Ürününüz kültür ve yaklaşımların uygulanmasıyla yönlendirilmemelidir. Bunu anlamak çok önemli, bu yüzden bu slayta bu kadar çok zaman ayırıyorum ve tüm bunları bu kadar uzun süre açıklıyorum.
Давайте поговорим про DevOps-практики в целом. Какие они есть? Чем они отличаются? Как их померить? Почему они важны?
Первая практика, о которой вы могли слышать, называется Continuous Integration. Возможно, у кого-то на проекте есть Continuous Integration (CI).
Самая большая проблема в том, что чаще всего, когда я спрашиваю у человека: «Есть ли у вас CI на проекте?» и он говорит: «Да», то, когда я спрашиваю, что он делает, он мне описывает абсолютно весь процесс автоматизации. Это не совсем так.
На самом деле практика CI всего лишь направлена на то, что код, который пишут разные люди, интегрируется в какую-то единую базу кода. Вот и все.
Вместе с CI по дороге идут обычно еще разные практики — такие, как Continuous Deployment, Release Management, но об этом мы поговорим потом.
Сам CI нам говорит, что разные люди пишут код и этот код должен интегрироваться непрерывно в единую базу кода.
Что это нам дает и почему это важно? Если у нас DotNet, то это хорошо, это компилируемый язык, мы можем скомпилировать наше приложение. Если оно компилируется, то это уже хороший знак. Это еще ничего не означает, но это уже первый хороший знак, что мы хотя бы можем скомпилироваться.
Потом мы можем запустить какие-то тесты, что тоже является отдельной практикой. Тесты все зеленые – это уже второй хороший знак. Но опять же это еще ничего не означает.
Но, зачем вам это делать? Все практики, о которых я буду рассказывать сегодня, под собой несут примерно одинаковый value, т. е. примерно одинаковые преимущества и меряются тоже примерно одинаково.
Первое – это позволяет вам ускорить доставку. За счет чего это позволяет вам ускорить доставку? Когда у нас заходят какие-то новые изменения в нашу кодовую базу, мы можем сразу же попытаться с этим кодом что-то сделать. Мы не ждем пока у нас придет четверг, потому что в четверг мы релизим это на QA Environment, мы делаем это прямо тут и прямо здесь.
Size hayatımdan üzücü bir hikaye anlatacağım. Uzun zaman önceydi, hâlâ genç ve yakışıklıyken. Artık gencim, güzelim, akıllıyım ve mütevazıyım. Bir süre önce bir projedeydim. Yaklaşık 30 geliştiriciden oluşan büyük bir ekibimiz vardı. Ve yaklaşık 10 yıldır gelişen çok büyük bir Enterprise projemiz vardı. Ve farklı şubelerimiz vardı. Depoda geliştiricilerin yürüdüğü bir şubemiz vardı. Ve kodun üretimdeki versiyonunu gösteren bir şube vardı.
Üretim şubesi, geliştiricilerin kullanımına sunulan şubenin 3 ay gerisindeydi. Bu ne anlama gelir? Bu, geliştiricilerin hatası nedeniyle, buna izin verdikleri için ve QA'nın hatası nedeniyle, ona baktıkları için üretime giden bir hatayla karşılaştığımda, bu şu anlama gelir: üretim için düzeltme görevi, ardından kod değişikliklerimi 3 ay önce geri almam gerekiyor. 3 ay önce yaşadıklarımı hatırlamam ve orada düzeltmeye çalışmam gerekiyor.
Если у вас не было еще такого опыта, то можете попробовать это сделать на вашем домашнем проекте. Главное, не пробуйте на коммерческом. Напишите пару строчек кода, забудьте о них на полгода, а потом вернитесь и попытайтесь быстро объяснить, о чем эти строчки кода и как можно их исправить или оптимизировать. Это очень-очень увлекательный опыт.
Sürekli Entegrasyon uygulamamız varsa, bu bize kodumu yazar yazmaz hemen burada ve hemen bir dizi otomatik araçla kontrol etmemizi sağlar. Bu bana resmin tamamını göstermeyebilir ama yine de en azından risklerin bir kısmını ortadan kaldıracaktır. Ve eğer potansiyel bir hata varsa, bunu hemen şimdi, yani kelimenin tam anlamıyla birkaç dakika içinde öğreneceğim. 3 ay geriye dönmeme gerek yok. Sadece 2 dakika geriye dönmem gerekecek. İyi bir kahve makinesinin kahveyi 2 dakikada hazırlamaya bile vakti olmaz, bu oldukça hoş.
Bu, her projede defalarca tekrarlanabilecek bir değere sahiptir; yalnızca sizin kurduğunuz kişi değil. Hem uygulamanın kendisini tekrarlayabilirsiniz hem de projede yaptığınız her yeni değişiklik için CI'nın kendisi tekrarlanacaktır. Bu, ekibinizin daha verimli çalışması nedeniyle kaynakları optimize etmenize olanak tanır. Artık 3 ay önce çalıştığınız koddan hata gelmesi gibi bir durumla karşılaşmayacaksınız. Artık oturup ilk iki saatinizi o anda ne olduğunu anlamaya çalışarak ve bir şeyi düzeltmeye başlamadan önce bağlamın özüne inerek geçirdiğinizde bağlam değiştirme olanağınız olmayacak.
Как можно померить успех или неуспех этой практики? Если отраппортовать большому боссу, что мы внедрили на проекте CI, то он слышит бла-бла-бла. Внедрили, Ок, а зачем, что это нам принесло, как мы это померим, насколько мы правильно или неправильно внедряем?
Первое, это то, что за счет CI мы можем делать деплой чаще и чаще, и чаще именно по той причине, что у нас потенциально это более стабильный код. Точно так же у нас уменьшается время на поиск ошибки и уменьшается время на исправление этой ошибки именно по той причине, что мы получаем ответ от системы прямо здесь и прямо сейчас, что с нашим кодом не так.
Другая практика, которая у нас есть, это практика Автоматического тестирования, которая чаще всего идет с практикой CI. Они идут рука об руку.
Что здесь важно понимать? Важно понимать, что тесты у нас бывают разные. И каждые автоматические тесты нацелены на решение своих задач. У нас есть, допустим, unit-тесты, которые позволяют нам протестировать отдельно какой-то модуль, т.е. как он работает в вакууме. Это хорошо.
Также у нас есть интеграционные тесты, которые позволяют нам понять, как разные модули интегрируются между собой. Это тоже хорошо.
У нас могут быть UI automation тесты, которые позволяют нам проверить, насколько работа с UI соответствует тем или иным требованиям, которые выставил заказчик и т.д.
Оттого, какие именно тесты вы запускаете, это может влиять на периодичность их запуска. Unit-тесты обычно у нас пишутся короткими, небольшими. И их можно запускать регулярно.
UI otomasyon testlerinden bahsediyorsak projenizin küçük olması iyidir. Kullanıcı arayüzü otomasyon testleriniz yeterli zaman alabilir. Ancak genellikle bir kullanıcı arayüzü otomasyon testi, büyük bir projede birkaç saat süren bir şeydir. Ve birkaç saat sürmesi iyi olur. Tek şey, bunları her yapı için çalıştırmanın bir anlamı olmamasıdır. Geceleri onları çalıştırmak mantıklıdır. Ve sabah herkes işe geldiğinde, hem test uzmanları hem de geliştiriciler, kullanıcı arayüzü otomatik testini gece çalıştırdığımıza ve bu sonuçları aldığımıza dair bir tür rapor aldılar. Ve burada, ürününüzün bazı gereksinimleri karşıladığını kontrol edecek bir sunucunun bir saatlik çalışması, yemek ve teşekkür için çalışan bir Kıdemsiz QA mühendisi olsa bile, aynı QA mühendisinin bir saatlik çalışmasından çok daha ucuz olacaktır. Yine de, makinenin bir saatlik çalışması daha ucuz olacaktır. Bu nedenle yatırım yapmak mantıklıdır.
Üzerinde çalıştığım başka bir projem daha var. Bu projede iki haftalık sprintlerimiz vardı. Proje büyüktü, finans sektörü için önemliydi ve hata yapılamazdı. İki haftalık bir sprint'in ardından geliştirme döngüsünü, 4 hafta daha süren bir test süreci izledi. Trajedinin boyutunu hayal etmeye çalışın. İki hafta boyunca kod yazıyoruz, ardından bunu CodeFreeze olarak yapıyoruz, uygulamanın yeni bir sürümünde paketliyoruz ve test kullanıcılarına sunuyoruz. Test uzmanları bunu 4 hafta daha test eder; Onlar test ederken bizim de onlara iki versiyon daha hazırlayacak vaktimiz var. Bu gerçekten üzücü bir durum.
И мы им сказали, что если вы хотите работать более продуктивнее, вам имеет смысл внедрять практику Автоматического тестирования, потому что это то, что у вас болит прямо здесь и прямо сейчас.
Практика Непрерывного развертывания. Отлично, вы сделали build. Это уже хорошо. У вас код скомпилировался. Теперь было бы неплохо этот build развернуть на каком-то окружении. Допустим, на окружении для разработчиков.
Neden önemlidir? Öncelikle dağıtım sürecinin kendisinde ne kadar başarılı olduğunuza bakabilirsiniz. Bunun gibi projelerle karşılaştım, "Uygulamanın yeni sürümünü nasıl dağıtırsınız?" diye sorduğumda, adamlar bana şunu söylüyor: "Bunu bir araya getiriyoruz ve bir zip arşivine paketliyoruz. Yöneticiye posta yoluyla gönderiyoruz. Yönetici bu arşivi indirir ve genişletir. Ve tüm ofis sunucunun yeni sürümü alması için dua etmeye başlıyor.”
Basit bir şeyle başlayalım. Örneğin arşive CSS koymayı unutmuşlar veya java-script dosya adındaki hashtag'i değiştirmeyi unutmuşlar. Ve sunucuya bir istekte bulunduğumuzda, tarayıcı bu java-script dosyasının zaten kendisinde olduğunu düşünüyor ve onu indirmemeye karar veriyor. Ve eski bir versiyon vardı, bir şeyler eksikti. Genel olarak birçok sorun olabilir. Bu nedenle, Sürekli Dağıtım uygulaması, en azından temiz bir referans görüntüsü alıp onu tamamen temiz yeni bir ortama yüklediğinizde ne olacağını test etmenize olanak tanır. Bunun nereye varacağını görebilirsiniz.
Кроме того, когда вы интегрируете код между собой, т.е. между командой, это позволяет вам также посмотреть, как это выглядит на UI.
Çok fazla standart Java betiği kullanıldığında ortaya çıkan sorunlardan biri, iki geliştiricinin pencere nesnesinde aceleyle aynı adı taşıyan bir değişken bildirmesidir. Ve sonra şansınıza bağlı olarak. Kimin java-script dosyası ikinci olarak çıkarılırsa diğerinin değişikliklerinin üzerine yazılacaktır. Aynı zamanda çok heyecan verici. İçeri girersiniz: Bir kişi için bir şey işe yarar, bir başkası için diğeri işe yaramaz. Ve her şeyin üretimde ortaya çıkması "harika".
Следующая практика, которая у нас есть, это практика Автоматического восстановления, а именно отката на предыдущую версию приложения.
Почему это важно для разработчиков? Есть еще те, кто помнят далекие-далекие 90-ые, когда компьютеры были большие, а программы маленькие. И путь в веб-разработку лежал только через php. Не то что бы php – это плохой язык, хоть это и так.
Ama sorun farklıydı. Php sitemizin yeni bir sürümünü dağıttığımızda onu nasıl dağıttık? Çoğu zaman Far Manager'ı veya başka bir şeyi açtık. Ve bu dosyaları FTP'ye yükledim. Ve aniden küçük, küçük bir hatamız olduğunu fark ettik, örneğin noktalı virgül koymayı unuttuk veya veritabanının şifresini değiştirmeyi unuttuk ve yerel ana bilgisayarda bulunan veritabanı için bir şifre var. Ve hızlı bir şekilde FTP'ye bağlanmaya ve dosyaları orada düzenlemeye karar veriyoruz. Bu sadece ateş! 90'lı yıllarda popüler olan şey buydu.
Ancak takvime bakmadıysanız 90'lı yıllar neredeyse 30 yıl önceydi. Şimdi her şey biraz farklı oluyor. Ve size şunu söylediklerinde trajedinin boyutunu hayal etmeye çalışın: “Üretime geçtik ama orada bir şeyler ters gitti. İşte FTP kullanıcı adınız ve şifreniz, üretime bağlanın ve sorunu orada hızla düzeltin." Eğer Chuck Norris'sen bu işe yarayacaktır. Aksi takdirde, bir hatayı düzeltirseniz 10 hata daha yapma riskiyle karşı karşıya kalırsınız.Bu, önceki sürüme geri dönme uygulamasının tam da bu nedenle çok şey başarmanıza olanak sağlamasının nedenidir.
Bir şekilde kötü bir şey bir şekilde ortaya çıksa bile, o zaman bu kötüdür, ancak ölümcül değildir. Sahip olduğunuz önceki sürüme geri dönebilirsiniz. Bu terminolojide algılamak daha kolaysa buna yedek deyin. Bu önceki sürüme geri dönebilirsiniz; kullanıcılar ürününüzle çalışmaya devam edebilir ve yeterli arabellek süreniz olur. Sakince, acele etmeden tüm bunları alıp yerel olarak test edebilir, düzeltebilir ve ardından yeni bir sürüm yükleyebilirsiniz. Bunu yapmak gerçekten mantıklı.
Теперь давайте попытаемся совместить где-то как-то две предыдущие практики вместе. Мы получим третью, которая называется Release Management.
Klasik haliyle Continuous Deployment'tan bahsettiğimizde repository'den bir daldan kod çekmemiz, derlememiz ve dağıtmamız gerektiğini söylüyoruz. Aynı ortama sahip olmamız iyi. Birden fazla ortamımız varsa, bu, aynı taahhütten bile olsa her seferinde kodu çekmemiz gerektiği anlamına gelir. Her seferinde çıkaracağız, her seferinde inşa edeceğiz ve yeni bir ortama yerleştireceğiz. Birincisi, zamanı geldi, çünkü büyük bir projeniz varsa ve 90'lardan geldiyseniz, bir proje inşa etmek birkaç saat sürebilir.
Кроме того, есть другая печаль. Когда вы будете билдить пускай даже на той же самой машине, вы будете билдить те же самые исходники, у вас все равно нет гарантии, что эта машина находится в том же состоянии, в котором она была во время прошлого билда.
Diyelim ki birisi geldi ve sizin için DotNet'i güncelledi veya tam tersi birisi bir şeyi silmeye karar verdi. Ve sonra, iki hafta önce bu taahhütten dolayı bir yapı oluşturduğumuza ve her şeyin yolunda olduğuna dair bilişsel bir uyumsuzluk var, ancak şimdi aynı makine, aynı taahhüt, oluşturmaya çalıştığımız aynı kod gibi görünüyor, ancak çalışmıyor . Uzun süre bununla uğraşacaksınız ve çözeceğiniz bir gerçek değil. En azından sinirlerinizi çok bozarsınız.
Поэтому практика Release Management предлагает внедрить дополнительную абстракцию, которая называется хранилище артефактов или галерея, или библиотека. Можно назвать как угодно.
Основная идея в том, что, как только у нас появляется там какой-то коммит, допустим, в ветке, которую мы уже готовы деплоить на наши разные окружения, мы собираем приложения из этого коммита и все, что нам надо для этого приложения, мы пакуем в zip-архив и сохраняем в каком-то надежном хранилище. И из этого хранилища мы этот zip-архив можем в любой момент достать.
Потом мы берем и автоматически разворачиваем его на dev-окружении. Там гоняем, и если все хорошо, то разворачиваем на stage. Если все хорошо, то разворачиваем на production один и тот же архив, одни и те же бинарники, скомпилированные ровно один раз.
Ayrıca böyle bir galeriye sahip olduğumuzda, son slaytta önceki sürüme geri dönüşten bahsederken değindiğimiz riskleri de ele almamıza yardımcı oluyor. Yanlışlıkla yanlış bir şey dağıttıysanız, her zaman bu galeriden herhangi bir önceki sürümü alıp bu ortamlara aynı şekilde dağıtmayı kaldırabilirsiniz. Bu, bir şeyler ters giderse kolayca önceki sürüme geri dönmenizi sağlar.
Есть еще одна великолепная практика. Все мы с вами понимаем, что, когда мы откатываем наши приложения на предыдущую версию, это может означать, что инфраструктура нам нужна тоже предыдущей версии.
Sanal altyapıdan bahsettiğimizde birçok kişi bunun yöneticilerin kurduğu bir şey olduğunu düşünüyor. Ve örneğin uygulamanızın yeni bir sürümünü test etmek istediğiniz yeni bir sunucuya ihtiyacınız varsa, o zaman yöneticilere veya geliştiricilere bir bildirim yazmanız gerekir. Bunun için Devops 3 hafta sürecektir. Ve 3 hafta sonra size, sizin için tek çekirdekli, iki gigabayt RAM'li ve DotNet'siz bir Windows sunucusu olan bir sanal makine kurduğumuzu söyleyecekler. "Ama ben DotNet'i istedim" diyorsunuz. Onlar: “Tamam, 3 hafta sonra tekrar gel.”
Идея в том, что, используя практику "Инфраструктура как код", вы можете относиться к вашей виртуальной инфраструктуре всего лишь как к еще одному очередному ресурсу.
Belki aranızdan DotNet üzerinde uygulama geliştiren varsa Entity Framework adında bir kütüphane duymuşsunuzdur. Hatta Entity Framework'ün Microsoft'un aktif olarak desteklediği yaklaşımlardan biri olduğunu duymuş olabilirsiniz. Bir veritabanıyla çalışmak için bu, Code First adı verilen bir yaklaşımdır. Bu, veritabanınızın nasıl görünmesini istediğinizi kodda açıkladığınız zamandır. Daha sonra uygulamayı dağıtırsınız. Veritabanına bağlanır, hangi tabloların orada olduğunu, hangilerinin olmadığını kendisi belirler ve ihtiyacınız olan her şeyi oluşturur.
Aynısını altyapınız için de yapabilirsiniz. Bir proje için veritabanına ihtiyacınız olması veya bir proje için Windows sunucusuna ihtiyacınız olması arasında hiçbir fark yoktur. Bu sadece bir kaynak. Ve bu kaynağın oluşturulmasını otomatikleştirebilirsiniz, bu kaynağın yapılandırmasını otomatikleştirebilirsiniz. Buna göre, her yeni konsepti, yeni bir yaklaşımı test etmek istediğinizde devops'a bilet yazmanıza gerek kalmayacak, hazır şablonlardan, hazır komut dosyalarından kendiniz için izole bir altyapıyı kolayca dağıtabilir ve uygulayabilirsiniz. tüm deneylerin orada. Bunu silebilir, bazı sonuçlar alabilir ve bu konuda daha fazla rapor verebilirsiniz.
Следующая практика, которая тоже есть и тоже важна, но которой мало кто пользуется, это Application Performance Monitoring.
Про Application Performance Monitoring хотел сказать только одну вещь. Что больше всего важно в этой практике? Это то, что Application Performance Monitoring – это примерно так же, как и ремонт в квартире. Это не финальное состояние, это процесс. Вам нужно его проводить регулярно.
По-хорошему было бы хорошо Application Performance Monitoring проводить чуть ли не на каждый build, хотя, как вы понимаете, далеко не всегда это возможно. Но, как минимум, на каждый релиз его нужно проводить.
Neden önemlidir? Çünkü aniden performansta bir düşüş yaşarsanız nedenini net bir şekilde anlamanız gerekir. Ekibinizin örneğin iki haftalık sprintleri varsa, o zaman en az iki haftada bir uygulamanızı açıkça sabitlenmiş bir işlemcinin, RAM'in, disklerin vb. bulunduğu ayrı bir sunucuya dağıtmalısınız. Ve aynı performans testlerini çalıştırmalısınız. . Sonucu alırsınız. Önceki sprint'e göre nasıl değiştiğini görün.
И если вы узнаете о том, что просадка пошла резко куда-то вниз, то это будет означать, что это было всего лишь из-за изменений, которые были на протяжении последних двух недель. Это позволит вам намного быстрее определить и исправить эту проблему. И опять это те же примерно метрики, по которым можно померить, насколько успешно это у вас получилось.
Следующая практика, которая у нас есть, это практика Configuration Management. Очень мало, кто относится к этому серьезно. Но, поверьте мне, это на самом деле очень серьезная штука.
Geçtiğimiz günlerde komik bir hikaye yaşandı. Adamlar yanıma gelip şöyle dediler: "Uygulamamızın güvenlik denetimini yapmamıza yardım edin." Uzun süre koda baktık, bana uygulamayı anlattılar, diyagramlar çizdiler. Ve artı veya eksi her şey mantıklı, anlaşılır, güvenliydi, ama bir tane vardı AMA! Kaynak kontrollerinde, IP veritabanıyla üretimdekiler de dahil olmak üzere, bu veritabanlarına bağlanmak için oturum açma bilgileri ve parolalar vb. içeren yapılandırma dosyaları vardı.
Ben de şunu söylüyorum: “Arkadaşlar, tamam, üretim ortamınızı bir güvenlik duvarı ile kapattınız, ancak üretim veritabanı için kullanıcı adı ve şifrenin doğrudan kaynak kontrolünde olması ve herhangi bir geliştiricinin bunu okuyabilmesi zaten büyük bir güvenlik riskidir. . Uygulamanız kod açısından ne kadar güvenli olursa olsun, eğer onu kaynak kontrolünde bırakırsanız hiçbir yerde hiçbir denetimden geçemezsiniz." Ben de bundan bahsediyorum.
Управление конфигурацией. На разном окружении у нас может быть разная конфигурация. Например, у нас могут быть разные логины и пароли для баз данных для QA, demo, production-окружения и т. д.
Bu yapılandırma aynı zamanda otomatikleştirilebilir. Her zaman uygulamanın kendisinden ayrı olmalıdır. Neden? Çünkü uygulamayı bir kez oluşturdunuz ve uygulama SQL sunucusuna falan filan IP üzerinden mi, falan filan IP üzerinden mi bağlandığınızı umursamaz, aynı şekilde çalışması gerekir. Bu nedenle, eğer biriniz birdenbire bağlantı dizesini koda kodlamaya başlarsa, o zaman kendinizi benimle aynı projede bulursanız sizi bulacağımı ve cezalandıracağımı unutmayın. Bu her zaman ayrı bir konfigürasyona, örneğin web.config'e yerleştirilir.
Ve bu konfigürasyon zaten ayrı ayrı yönetiliyor, yani bu tam olarak geliştiricinin ve yöneticinin gelip aynı odada oturabileceği andır. Ve geliştirici şöyle diyebilir: “Bakın, işte uygulamamın ikili dosyaları. Çalışırlar. Uygulamanın çalışması için bir veritabanına ihtiyacı var. Burada ikili dosyaların yanında bir dosya var. Bu dosyada bu alan girişten sorumludur, bu şifre içindir, bu IP içindir. Herhangi bir yere konuşlandırın." Ve yönetici için basit ve anlaşılır. Bu yapılandırmayı yöneterek onu gerçekten her yere dağıtabilir.
И последняя практика, о которой хотел бы сказать, это практика, которая очень-очень сильно относится к облакам. И максимальный эффект она приносит, если вы работаете в облаке. Это Автоматическое удаление вашего окружения.
Я знаю, что на этой конференции присутствуют несколько людей из тех команд, с которыми я работаю. И со всеми командами, с которыми я работаю, мы используем вот эту практику.
Neden? Elbette her geliştiricinin 24/7 çalışacak bir sanal makinesi olsa harika olurdu. Ama belki bu sizin için yeni bir haber, belki dikkat etmediniz ama geliştiricinin kendisi 24/7 çalışmıyor. Bir geliştirici genellikle günde 8 saat çalışır. İşe erken gelse bile büyük bir öğle yemeği yiyor ve bu sırada spor salonuna gidiyor. Geliştiricinin bu kaynakları gerçekten kullandığı günün 12 saati olsun. Mevzuatımıza göre haftanın 5 gününün 7'i iş günü olarak kabul edilmektedir.
Buna göre hafta içi bu makinenin 24 saat değil sadece 12 saat çalışması, hafta sonları ise bu makinenin hiç çalışmaması gerekiyor. Görünüşe göre her şey çok basit ama burada söylenecek önemli olan ne? Bu basit uygulamayı bu temel programa uygulayarak, bu ortamların bakım maliyetini %70 oranında azaltmanıza olanak tanır; yani geliştiricinizin, QA'nızın, demonuzun, ortamınızın fiyatını aldınız ve bunu 3'e böldünüz.
Вопрос, что делать с остальными деньгами? Например, купить разработчикам ReSharper, если еще не купили. Или устроить коктейльную вечеринку. Если у вас раньше было одно окружение, на котором паслись и dev, и QA, и все, то теперь вы можете сделать 3 разных, которые будут изолированы, и люди не будет мешать друг другу.
Что касается слайда с постоянным замером производительности, как можно сравнить производительность, если у нас в проекте было 1 000 записей в базе данных, через два месяца их миллион? Как понять, почему и какой смысл в замере производительности?
Bu iyi bir soru çünkü performansı her zaman aynı kaynaklarda ölçmelisiniz. Yani yeni kodu yayınlarsınız, yeni kodun performansını ölçersiniz. Örneğin farklı performans senaryolarını test etmeniz gerekiyor, diyelim ki uygulamanın 1 kullanıcının olduğu ve veritabanı boyutunun 000 gigabayt olduğu hafif bir yükte nasıl performans gösterdiğini test etmek istiyorsunuz. Ölçtünüz ve rakamları aldınız. Sonra başka bir senaryo alıyoruz. Örneğin 5 kullanıcı, veritabanı boyutu 5 terabayt. Sonuçları aldık ve hatırladık.
Burada önemli olan ne? Burada önemli olan senaryoya, veri hacmine, eş zamanlı kullanıcı sayısına vb. bağlı olarak belirli limitlerle karşılaşabilmenizdir. Örneğin, bir ağ kartının sınırına, bir sabit sürücünün sınırına veya işlemci yeteneklerinin sınırına kadar. Anlamanız için önemli olan budur. Farklı senaryolarda belirli sınırlarla karşılaşırsınız. Ve sayıları vurduğunuzda anlamalısınız.
Тут речь идет о замере производительности на специальном тестовом окружении? Т. е. это не production?
Да, это не production, это тестовое окружение, которое всегда одинаковое, чтобы вы могли сравнить его с предыдущими замерами.
Anladım, teşekkürler!
Soru yoksa bitirebiliriz diye düşünüyorum. Teşekkür ederim!
Kaynak: habr.com