თქვენ ფიქრობთ, რომ სწორია ერთ workflow-ში გაერთიანდეს ბილდინგი, ტესტირება და იმიჯის გამოქვეყნება, ასევე დაამატოთ ნაბიჯები სხვადასხვა გარემოებისთვის განთავსებისთვის?

ეს ყოველთვის არ არის ოპტიმალური. მიუხედავად იმისა, რომ ასეთი მიდგომა შეიძლება იყოს მოსახერხებელი მცირე პროექტებისთვის ან ადგილობრივ ტესტირების ნაკრებისთვის, ყველა ეტაპის ერთ სამუშაო პროცესში გაერთიანება აქვს ნაკლოვანებები:

• სხვაობის შემცირება: სხვადასხვა გარემოში (dev, staging, production) განთავსება მოითხოვს სხვადასხვა პარამეტრებს და ხშირად სხვადასხვა წვდომის უფლებებს. გაერთიანება ამ განსხვავებების მართვას ამძიმებს:
• გარემოს დამოკიდებულება: თუ განთავსება ერთ გარემოში ვერ მოხერხდა, მთელი შეკვეთა ჩაითვლება წარუმატებლად, მიუხედავად იმისა, რომ იმიჯის შეკვეთა და მისი ტესტირება წარმატებით დასრულდა:
• გადატვირთვის სირთულე: განთავსების გადატვირთვა ხდება ნაკლებად მარტივი, რადგან საჭიროა მთელი workflow-ის გადატვირთვა:
• მუშაობის დროის გაზრდა: მთელი pipeline მეტ დროს იღებს, რაც აჩერებს დეველოპერების უკუკავშირს:
• მცირე მასშტაბურობა: როდესაც პროექტი იზრდება და განთავსების გარემოების რაოდენობა იზრდება, ასეთი workflow ხდება მძიმე და რთულად მართვადი:

მეტი გავრცელებული და მოქნილი პრაქტიკაა ამ ეტაპების გაყოფა:

1. Build & Test Pipeline: პასუხისმგებელია კოდის შეკრებაზე, ტესტირებაზე, იმიჯის შექმნაზე და მისი შენახვაზე არტეფაქტების რეგისტრში (მაგ., Docker Registry, Nexus). ეს workflow იწყება ყოველ კომიტზე ან pull request-ზე:
2. Deployment Pipelines: ცალკეული workflow-ები განთავსებისთვის თითოეულ გარემოში. ისინი იღებენ უკვე შეკრებილ და ტესტირებულ იმიჯს არტეფაქტების რეგისტრიდან და განთავსებენ მას მიზნობრივ გარემოში. ეს workflow-ები შეიძლება დაიწყოს ხელით, განრიგით ან ავტომატურად, წარმატებული დასრულების შემდეგ (მაგ., წარმატებული განთავსება staging-ში):

ეს საშუალებას აძლევს:

• უფრო სწრაფად მიიღოთ უკუკავშირი კოდის ხარისხზე (build & test):
• განთავსება სხვადასხვა გარემოში დამოუკიდებლად:
• უფრო მოქნილი მართვა განთავსების პარამეტრებისთვის თითოეულ გარემოში:
• პროცესის გამარტივება გადატვირთვის:

შესაძლოა, მცირე pet-პროექტებისთვის ან მარტივი განთავსების პროცესის მქონე მონოლითურ აპლიკაციებისთვის, სადაც გაყოფის ხარჯები სარგებელს აღემატება. თუმცა, უმეტეს ორგანიზაციულ გარემოებში workflow-ის გაყოფა საუკეთესო პრაქტიკაა.