1. Srm Ynetiminin aslnda esas hedefi ve ktssalkl Srm Notlardr. Srm Notlar bir yazlma ait ilerin (new feature & bug fix) ne zaman ve hangi srmde devreye alnacan veya alndn gsterir.

2. Salkl bir Srm Notu hazrlamak iinncelikle gzel bir araca ihtiyacmz var. Biz JIRAy tercih ediyoruz. 3. Gelitirdiimiz proje, rn, uygulama vs. ile ilgili hertrl konuyu (bug, task, new feature, improvement, problem, support request, etc.) Issue Tracking Tool zerinden takip etmemiz gerekiyor. 4. Herhangi bir ortamda (DEV, TEST, PROD) uygulamakullanlrken tespit edilen hatalar takip sistemine girilirken (affect version) kullanlmaldr. Bu sayede hatann hangi versiyonda ortaya kt belli olacak ve Srm Notlarnda gzkecektir. 5. Bir hata zldnde veya bir istektamamlandnda bu iin hangi srmle (fix version) devreye alnaca mutlaka Takip Arac'nda belirtilmelidir. Bu bilgi Srm Notlarnn hazrlanabilmesi iin ok nemlidir. Bu bilgileri kullanarak Srm Notlarn online olarak takip edebiliriz. 6. Srm Ynetimi asndan en nemli konulardan biride kodlar'daki deiikliklerin srm kapsamnda yaplp yaplmadnn kontroldr. Hi kimse kapsam dndaki bir deiikliin production ortamna alnmasn istemez. Bunun nlemenin en iyi yolu Versiyon Kontrol Aralarndaki deiikliklerin, Takip Aralarndaki konularla ilikilendirilmesidir. 7. Eer developer'lar her check-in yaptklarnda, kod'unierisinde ilgili yere bu deiikliin nedeni olan IssueKey'i comment olarak yazarlarsa, JIRA ve CVS'in entegre olduu durumlarda bu deiiklik JIRA'daki ilgili issue ile ilikilendirilir ve raporlanr. Biz git zerinden branch sistemi ile gitmeyi tercih ediyoruz. Bunun avantajlar ve dez avantajlar vardr. 8. Bir srm kapsamndaki ilerin bamllklarnn takipedilmesi ok nemlidir. rnein 2.1.7 srmnde kartacanz bir iyiletirmenin bir paras 2.2.0 srmde kartmay planladnz bir iyiletirmeye baml ise Srm Plann tekrardan yapmanz gerekecektir. Burada esas sorun plann tekrar yaplmas deil bu bamlln nceden ve kolayca tespit edilebilmesidir. 9. Her developer ve QA'in production ortamnnreplikas olan testboxlar var. 10. Developerlar test edilmeye gndermeden nceyazdklar kodu jiradaki issue numarasn verdikleri branchlere merge ediyorlar ve testboxlarna deploy edip kontrol ediyorlar. 11. Teste gelen iler masterla merge edilip QAtarafndan testboxlara deploy edip sadece yaplan kod deiikliini test ediyorlar. 12. Testten geen issue'larn branchleri dev-ops ekibitarafndan kendi yazdmz bir scriptle birletirilip fix versionlar ekleniyor. kan conflictler dev-ops ekibinin takibinde conflict kan branchin developer' tarafndan dzeltiliyor. Bu ilemler tamamlandktan sonra release paketi devops ekibi tarafndan testbox'a deploy ediliyor ve eer varsa operation document'i uygulanyor (SQL,curl etc.) 13. QA otomasyon ekibi otomatik testleri bu paketzerinde altryor. Ve Qa manuel ekibi system checklisti uyguluyor. Bu aamaya pre-production testi diyoruz. Testten geen paket onaylanp dev-ops ekibine gnderiliyor . 14. Dev-ops tarafndan release rename ediliyor vesystem-admin ekibine deployment approval statusuna gnderiliyor. 15. Deployment yapldktan sonra QA release notes'uyaynlyor. Post-production testi yaplp issuelar kapatlyor. Karlalan buglar affected version eklenerek jiraya alyor.