წყაროს მართვა
დააკავშირეთ GitHub ან GitLab ანგარიში, რომელშიც მუშაობთ და განათავსეთ პირდაპირ ტოტიდან: Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps ან AWS Amplify პლატფორმებზე — ან ჩვენს საკუთარ მართვად ჰოსტინგზე, სადაც რეპოზიტორია და საიტის ფაილები ორივე მიმართულებით სინქრონიზებული რჩება. თითოეული კავშირი აჩვენებს საჭირო პრივილეგიებს, შენახვამდე მოწმდება პროვაიდერის API-სთან და ინახება Vault-ში. ასევე შეგიძლიათ შეხვიდეთ GitHub-ის ან GitLab-ის მეშვეობით.
კავშირი არის ავტორიზაციის მონაცემი, რომელსაც სხვას გადასცემთ. ჩვენი სისტემა შექმნამდე გატყობინებთ, რა არის საჭირო, შენახვამდე ადასტურებს მის გამართულ მუშაობას და მისი გაუქმება შესაძლებელია ნებისმიერი მხრიდან.
სანამ ტოკენს შექმნით, გეუბნებით, რისი გაკეთება უნდა შეეძლოს მას და რატომ. არანაირი ზოგადი წვდომის არეალი მხოლოდ იმიტომ, რომ მისი მოთხოვნა უფრო მარტივი იყო, და არანაირი ფაქტის შემდგომ აღმოჩენა, რომ იმაზე მეტი გვინდოდა, ვიდრე სამუშაოს სჭირდებოდა.
თქვენი ტოკენის შენახვამდე, ჩვენ მას ვიყენებთ პროვაიდერის საკუთარი API-ის გამოსაძახებად. არასწორი, ვადაგასული ან არასწორი არეალის მქონე ტოკენი უარყოფილია უშუალოდ ფორმაში, ნაცვლად იმისა, რომ მიღებულ იქნეს, გამოჩნდეს გამართულად და ჩაიშალოს პირველივე რეალური განთავსებისას.
არც ჩვენს კოდში, არც გარემოს ფაილში, არც ჟურნალში და არც ბრძანების სტრიქონში. წყდება მისი გამოყენების მომენტში, იმ სამუშაო დატვირთვის მიერ, რომელიც მას იყენებს.
დააკავშირეთ პირადი ანგარიში ორგანიზაციის ანგარიშთან, ან ორი ორგანიზაციის ანგარიშები ერთმანეთთან. თითოეული საიტი ირჩევს, თუ რომელიდან განახორციელოს გაშვება, ამიტომ კლიენტის რეპოზიტორია და თქვენი საკუთარი არასდროს იზიარებენ საიდენტიფიკაციო მონაცემებს.
რვა მართული პერიფერიული ჰოსტი და ჩვენი საკუთარი ფლოტი. დანიშნულება საიტის თვისებაა და არა კავშირის, ასე რომ ერთსა და იმავე რეპოზიტორიას შეუძლია ერთი განშტოების გამოქვეყნება Pages ჰოსტზე, ხოლო მეორე საიტს შეუძლია იმუშაოს ჩვენს აპარატურაზე.
ულიმიტო გამტარუნარიანობა, დაშვებული კომერციული გამოყენება და apex დომენების მართვა იმავე პროვაიდერთან, რომელიც ჩვეულებრივ შეიცავს თქვენს DNS ზონას. სწორედ ამ მიზეზების გამო, ეს არის პირველი არჩევანი, რომელსაც მივმართავთ.
Cloudflare Pages ჰოსტინგი →გამოაქვეყნეთ პირდაპირ იმ საცავიდან, რომელშიც კოდი უკვე მდებარეობს. მონიშნულია Footprint-Free ხაზზე, რადგან გაზიარებული github.io ინფრასტრუქტურა თავად წარმოადგენს კვალს.
GitHub Pages ჰოსტინგი →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps და AWS Amplify წარმოადგენს მიმართულებებს, რომლებზეც შეგიძლიათ საიტის მიმართვა იგივე კავშირითა და განთავსების იგივე ისტორიით.
სტატიკური საიტის ჰოსტინგი →სრული აპლიკაცია და არა აწყობილი პაკეტი — WordPress, PHP, Node. ეს არის დანიშნულების ადგილი, რომელიც იღებს ორმხრივ სინქრონიზაციას, რათა სერვერზე და განშტოებაში არსებული ფაილები თანხვედრაში დარჩეს.
მართული ჰოსტინგი →საიტი, რომელიც გამოქვეყნებულია ჰოსტზე, რომელიც ჩვენ არ გვეკუთვნის, მაინც მოიხმარს ლიმიტს და კვლავ გამოჩნდება თქვენს მართვის პანელზე თავისი განთავსებებით, უწყვეტი მუშაობის დროითა და SEO მონაცემებით იმ ყველაფრის გვერდით, რასაც მართავთ.
გარე საიტების ლიმიტები →ბრაუზერში ჩაშენებული რედაქტორი მუშაობს იმავე ფაილებზე, რომლებსაც ორმხრივი სინქრონიზაცია უკან აგზავნის, ასე რომ მართვის პანელიდან სწრაფი შესწორება ხდება commit თქვენს შტოში იმ ცვლილების ნაცვლად, რომელსაც მოგვიანებით ვერავინ იპოვის.
ვებ რედაქტორი →ორმხრივი სინქრონიზაცია
ჩართეთ ის და საიტის საკუთარი ფაილები დაბრუნდება თქვენს განშტოებაში, ხოლო ამ განშტოების commit-ები დაბრუნდება საიტზე. ეს მუშაობს ყველა საიტზე, რომელსაც ჩვენ ვჰოსტავთ, თითოეულ ხაზზე — ერთადერთი მოთხოვნაა, რომ ქვემდებარე მანქანას შეეძლოს Git-ის გაშვება თავისი ფაილების წინააღმდეგ, რაც მოეთხოვება სერვერს და არა ნავარაუდები გეგმიდან.
თქვენ ირჩევთ, რომელი დირექტორია დასინქრონირდეს, რადგან WordPress-ის მომხმარებელს სურს საკუთარი თემის თვალის დევნება და არა ორმოცი ათასი ძირითადი ფაილის. და ის გამორთულია, სანამ არ ჩართავთ: სინქრონიზაციის ჩართვა სხვისი რეპოზიტორიის შესახებ მიღებული გადაწყვეტილებაა და მიგრაციამ ეს გადაწყვეტილება არასდროს არ უნდა მიიღოს თქვენ ნაცვლად.
ორი რეჟიმი, და განსხვავება იმაშია, თუ სად ეშვება ბილდი. ორივე ერთსა და იმავე ადგილზე სრულდება: რეფერენსი, რომელსაც ამოვიღებთ და ვაქვეყნებთ, ხოლო კომიტი ფიქსირდება განთავსებასთან ერთად.
GitHub ან GitLab, კავშირების ქვეშ. პრივილეგიები ჩამოთვლილია ტოკენის შექმნამდე და ის მოწმდება პროვაიდერთან შენახვამდე.
მფლობელი, საცავი, შტო და ვაქვეყნებთ კატალოგს თუ მომაქვს ის, რაც თქვენმა CI-მ შექმნა. ამის ფარგლებში ჩვენ ვარეგისტრირებთ push webhook-ს.
მითითებულ განშტოებაში გაგზავნა (push) იწყებს განთავსებას, ან შეგიძლიათ განათავსოთ მოთხოვნისამებრ საიტის განთავსების ჩანართიდან. აგებები ეშვება ფონურ რეჟიმში.
განთავსების ისტორია აჩვენებს, თუ რა გამოქვეყნდა და როდის. ჩართეთ ორმხრივი სინქრონიზაცია და ცვლილებები, რომლებსაც აქ განახორციელებთ, თქვენს შტოში commit-ების სახით დაბრუნდება.
როდესაც რამე რიგზე არ არის
რეპოზიტორიის კავშირი, რომელიც გამართულად გამოიყურება და არაფერს იღებს, კლასიკური ფარული შეცდომაა — არასწორი არეალის (scope) მქონე ტოკენი, პროვაიდერთან დაბლოკილი მიწოდება, ხელით წაშლილი ჰუკი (hook). ეს სხვა არცერთ ეკრანზე არ ჩანს, ამიტომ რეპოზიტორიის ბარათზე პირდაპირ აისახება: როდის განახორციელა პროვაიდერმა ბოლო მიწოდება და რა პასუხი მიიღო.
მიწოდებები მოქმედების განხორციელებამდე მოწმდება ხელმოწერით, თითოეული პროვაიდერის საკუთარი სქემით და არა იმით, რომელიც, ჩვენი ვარაუდით, ყველასთვის გამოიყენებოდა. მიწოდება, რომელიც არ დამოწმდება, უარყოფილია და ფიქსირდება, ნაცვლად იმისა, რომ ჩუმად იქნეს იგნორირებული.
იდენტურობა
ელფოსტის მისამართთან და პაროლთან ერთად, შეგიძლიათ თქვენს Zinn Digital® ანგარიშში შეხვიდეთ GitHub-ის, GitLab-ის, Google-ის ან Microsoft-ის მეშვეობით. იდენტიფიკაციის შრე ასრულებს დაკავშირებას (handshake); ჩვენ ვერასდროს ვხედავთ თქვენი პროვაიდერის პაროლს, ხოლო სოციალური ანგარიშის არსებულ Zinn® ანგარიშთან დაკავშირება კვლავ საჭიროებს ელფოსტით დადასტურებას.
GitHub-ით შესვლა და დეპლოისთვის GitHub-ის დაკავშირება ცალკეული გადაწყვეტილებები და ცალკეული ავტორიზაციის მონაცემებია. ერთის გაკეთება არ იწვევს მეორის გაკეთებას და ერთის წაშლა არ შლის მეორეს.
GitHub და GitLab. დააკავშირეთ ანგარიში, რომელშიც უკვე მუშაობთ, და ჩვენ შევძლებთ მისი რეპოზიტორიებიდან განთავსებას, მათზე push webhook-ის რეგისტრაციას და — თუ გსურთ — თქვენი საიტის ფაილების საპირისპირო მიმართულებით სინქრონიზაციას. ორივე გადის დაკავშირებული ანგარიშის ერთსა და იმავე კვანძზე, ამიტომ ქვემოთ მოცემული ყველაფერი ეხება ორივეს.
დიახ, ასევე Google-ით ან Microsoft-ით. ელფოსტის მისამართთან და პაროლთან ერთად, თქვენ შეგიძლიათ შეხვიდეთ თქვენს Zinn Digital® ანგარიშზე ამ ოთხიდან ნებისმიერით. იდენტიფიკაციის დონე მართავს დაკავშირების პროცესს (handshake) და ჩვენ არასდროს ვხედავთ თქვენი პროვაიდერის პაროლს. GitHub-ით შესვლა განსხვავდება დეპლოისთვის GitHub-ის დაკავშირებისგან — შეგიძლიათ აირჩიოთ რომელიმე მათგანი, ორივე, ან არცერთი.
Cloudflare Pages-ზე, GitHub Pages-ზე, GitLab Pages-ზე, Netlify-ზე, Vercel-ზე, Render-ზე, Azure Static Web Apps-ზე ან AWS Amplify-ზე სტატიკური თუ აწყობილი საიტისთვის — ან ჩვენს საკუთარ მართვად ჰოსტინგზე, სადაც რეპოზიტორია და საიტის ფაილები ორივე მიმართულებით სინქრონიზებული რჩება. თქვენ ირჩევთ საიტის დანიშნულების ადგილს; რეპოზიტორიის კავშირი ორივე შემთხვევაში ერთნაირია.
ნებისმიერი მათგანი. გამოქვეყნების რეჟიმში ჩვენ ვიღებთ განშტოებას ისეთს, როგორიც არის, და ვაქვეყნებთ თქვენ მიერ მითითებულ დირექტორიას. CI რეჟიმში თქვენი პროვაიდერის საკუთარი მიმდინარეობა (pipeline) უშვებს თქვენი აგების (build) ბრძანებას და შედეგს აგზავნის ცალკე გამოქვეყნების განშტოებაში, რომელსაც შემდგომ ვიღებთ, როგორც ნებისმიერ სხვა რეფერენსს. მეორე ვარიანტი ინახავს თქვენს აგების პროცესს თქვენსავე CI-ში, სადაც თქვენი საიდუმლოებები და ქეშირება უკვე მდებარეობს.
ნაგულისხმევად, დიახ — ჩვენ ვარეგისტრირებთ webhook-ს რეპოზიტორიაში და თქვენ მიერ მითითებულ განშტოებაში push იწყებს განთავსებას (deploy). შეგიძლიათ გამორთოთ ეს ფუნქცია და შეინარჩუნოთ webhook, რაც იმაზე მეტად სასარგებლოა, ვიდრე ჩანს: მიწოდება მაინც იწერება, ასე რომ თქვენ შეგიძლიათ თვალი ადევნოთ თქვენი push-ების მოსვლას, სანამ ჩვენ მათზე რეაგირების ნებას მოგვცემთ.
ჩვენს აპარატურაზე განხორციელებული ცვლილებები ხდება commit-ები თქვენს branch-ზე, ხოლო თქვენს branch-ზე არსებული commit-ები ბრუნდება საიტზე. ის გამორთულია მანამ, სანამ არ ჩართავთ, რადგან მისი ჩართვა სხვის რეპოზიტორიასთან დაკავშირებული გადაწყვეტილებაა და ამას თქვენ ნაცვლად ჩვენ არ გავაკეთებთ. თქვენ ირჩევთ, რომელი დირექტორიის სინქრონიზაცია მოხდეს — ჩვეულებრივ თემის ან დანამატის, და არა WordPress-ის ორმოცი ათასი ძირითადი ფაილის.
არაფერი გადაიწერება და არაფერი გაიგზავნება. სინქრონიზაცია ჩერდება, გატყობინებთ, რომ განშტოება გასცდა იმ commit-ს, რომელსაც ჩვენ დავეფუძნეთ, და გეკითხებათ, რომელი მხარე გსურთ — შეინარჩუნოთ საცავი თუ შეინარჩუნოთ საიტი. საიტი, რომელსაც არასდროს გაუვლია სინქრონიზაცია და მიუთითებს განშტოებაზე, რომელსაც უკვე აქვს commit-ები, ასევე წარმოადგენს ცალკე მდგომარეობას, და ის კითხულობს, ნაცვლად იმისა, რომ გამოიცნოს, რომელია ჭეშმარიტი.
კავშირის შექმნამდე გაჩვენებთ იმ პრივილეგიებს, რომლებიც მას სჭირდება, შეყვანისას ვამოწმებთ ტოკენს თავად პროვაიდერის API-სთან — ასე რომ, არასწორი ან არასწორი არეალის მქონე ტოკენი საერთოდ არ ინახება — და მხოლოდ ამის შემდეგ ვწერთ მას Vault-ში. ის არასდროს ეხება ჩვენს კოდს, ჟურნალს, გარემოს ფაილს ან ბრძანების სტრიქონს. გააუქმეთ იგი პროვაიდერთან ან წაშალეთ კავშირი აქ, როცა გსურთ.
რეპოზიტორიის ბარათი აჩვენებს, როდის განახორციელა პროვაიდერმა ბოლო მოწოდება ჩვენთან და რა თქვა მან. „არასოდეს მოწოდებულა“ ამ ეკრანზე ყველაზე სასარგებლო დიაგნოსტიკური მაჩვენებელია, რადგან „დაკავშირებულია, მაგრამ არასოდეს მოწოდებულა“ ზუსტად ისე გამოიყურება, როგორც არასწორი მოქმედების არეს მქონე თოკენი ან დაბლოკილი მიწოდება — და ის სხვაგან არსად ჩანს. ყოველი მიწოდება ხელმოწერით მოწმდება, სანამ მასზე ვიმოქმედებთ.
ეს ხელმისაწვდომია და მონიშნულია. GitHub Pages და GitLab Pages იზიარებენ პროვაიდერის ინფრასტრუქტურასა და საჯარო github.io და gitlab.io ჰოსტის სახელებს, რაც საძიებო სისტემების კვალს წარმოადგენს — ზუსტად იმას, რის თავიდან ასაცილებლადაც ეს ხაზი არსებობს. ნულოვანი კვალის მქონე ქსელისთვის, ამის ნაცვლად განათავსეთ იზოლირებულ ჰოსტინგზე. ყველა სხვა შემთხვევაში, Pages პირველი კლასისაა.
რადგან მისი უფასო პაკეტი ლიცენზირებულია მხოლოდ არაკომერციული გამოყენებისთვის. ჩვენ ვადგენთ დანიშნულების ადგილს თქვენ მიერ დაკავშირებული ანგარიშებიდან, სადაც ეს უსაფრთხოა, ხოლო Vercel განზრახ არის გამორიცხული ამ ლოგიკიდან — ანგარიშის დაკავშირებამ არასოდეს არ უნდა განათავსოს კომერციული საიტი ჩუმად იქ, სადაც მისი ლიცენზია ამას არ ითვალისწინებს. აირჩიეთ იგი და ის ზუსტად ისევე იმუშავებს, როგორც სხვები.
დიახ. ყოველი დეპლოი აღრიცხავს გამოქვეყნებულ commit-ს, გაშვების დროსა და დასრულების შედეგს, ხოლო საიტის Deploy ჩანართი აჩვენებს ისტორიას გვერდით არსებულ აქტიურ URL-თან ერთად. დეპლოი ფონურ რეჟიმში მუშაობს, ამიტომ გვერდი განახლდება აწყობის დასრულებისთანავე, ნაცვლად იმისა, რომ ჩატვირთვის ინდიკატორის ყურებაში გაცდევინოთ დრო.
დაიწყეთ 14-დღიანი საცდელი პერიოდი ბარათის გარეშე, დააკავშირეთ GitHub ან GitLab და მიმართეთ საიტი განშტოებაზე. გამოაქვეყნეთ edge ჰოსტზე ან ჩვენს საკუთარ ჰოსტინგზე ფაილების ორმხრივი სინქრონიზაციით.
დაიწყეთ უფასოდ