การใช้พื้นที่เก็บข้อมูล Apt สำหรับการอัปเดตซอฟต์แวร์ที่ต้องชำระเงิน

ฉันกำลังพยายามหาวิธีที่จะแจกจ่ายการปรับปรุงซอฟต์แวร์สำหรับเว็บแอปพลิเคชันที่โฮสต์ / บนเว็บไซต์ซึ่งอาจมีการอัปเดตรายสัปดาห์และ / หรือรายเดือน ฉันไม่ต้องการให้ลูกค้าที่ใช้ผลิตภัณฑ์ในสถานที่ต้องกังวลเกี่ยวกับการอัปเดตด้วยตนเองฉันแค่ต้องการให้ดาวน์โหลดและติดตั้งโดยอัตโนมัติ ala Google Chrome ฉันวางแผนที่จะให้ไฟล์ OVF กับ Ubuntu และซอฟต์แวร์ที่ติดตั้งและกำหนดค่า

ความคิดแรกของฉันเกี่ยวกับวิธีการแจกจ่ายซอฟต์แวร์คือการสร้างคลังเก็บ Apt / หกช่องทาง (ไม่แน่ใจว่าจะดีกว่า ณ จุดนี้) ที่จะเข้าถึงผ่าน SSH โดยใช้คีย์ดังนั้นหากลูกค้าไม่ต่ออายุการสมัครสมาชิกของเรา :

1. เบต้า - ใช้ภายในกับข้อมูลการทดสอบเพื่อตรวจสอบข้อบกพร่องที่สำคัญ
2. ภายใน - ใช้ภายในกับข้อมูลสดเพื่อตรวจสอบข้อบกพร่อง (ขั้นตอนการให้อาหารสุนัข)
3. ภายนอก 1 - ปรับใช้กับ 1% ของฐานผู้ใช้ของเรา (สุ่มเลือก) เพื่อตรวจสอบข้อบกพร่อง
4. ภายนอก 9 - ปรับใช้เป็น 9% ของฐานผู้ใช้ของเรา (สุ่มเลือก) เพื่อตรวจสอบข้อบกพร่อง
5. ภายนอก 90 - ปรับใช้กับผู้ใช้ 90% ที่เหลือ
6. โฮสต์ - ปรับใช้กับสภาพแวดล้อมที่โฮสต์

จะมีการลงชื่อออกในแต่ละขั้นตอนเพื่อย้ายไปยังที่เก็บถัดไปในกรณีที่รายงานปัญหา

คำถามของฉันต่อชุมชนคือ:

1. มีใครเคยลองแบบนี้มาก่อนบ้างไหม?
2. ทุกคนสามารถเห็นข้อเสียของขั้นตอนประเภทนี้หรือไม่?
3. มีวิธีที่ดีกว่า?

โดยรวมแล้วฉันชอบวิธีการนี้มาก ปัญหาการละเมิดลิขสิทธิ์ไม่สามารถโต้กลับได้ไม่ว่าจะเป็นการแจกจ่ายแบบดั้งเดิมหรือแบบอัตโนมัติและคุณสามารถหลีกเลี่ยงความไม่สะดวกของรูปแบบการออกใบอนุญาต

คุณอาจพบปัญหากับการเลือกแบบสุ่ม ลูกค้าได้รับเลือกให้เป็นผู้รับช่วงต้นตลอดช่วงเวลาของความสัมพันธ์ทางธุรกิจของคุณหรือไม่? หากไม่สามารถปรับลดรุ่นจากภายนอก 1 เป็น 9 ได้อย่างไร

คุณคิดเกี่ยวกับการอนุญาตให้ใช้สิทธิทั่วไปและการป้องกันประเภทโทรศัพท์ที่บ้านสำหรับซอฟต์แวร์ของคุณหรือไม่?

ปัญหาที่ฉันเห็นที่นี่ (ไม่มีใบอนุญาตใด ๆ ) คือฉันสามารถจ่ายเงินเป็นเวลาหนึ่งเดือนหยุดแล้วก็ทำงานในรุ่นนี้ต่อไป แน่นอนว่ามันเก่า แต่ฟรี อย่างน้อยบางคนก็หาช่องโหว่นี้ได้

หากคุณมีสิทธิ์ใช้งานอยู่แล้วเพียงแค่มีที่เก็บข้อมูลที่ไม่มีการป้องกันอย่างง่ายกับซอฟต์แวร์ที่ต้องตรวจสอบสิทธิ์การใช้งานก่อนใช้งาน

ฉันไม่รู้เกี่ยวกับซอฟต์แวร์และ / หรือลักษณะของลูกค้าของคุณมากพอ แต่ในหลาย ๆ ที่การปรับปรุงไม่ได้รับการติดตั้งโดยไม่ต้องทำการทดสอบ หลาย บริษัท ใช้รหัสใบอนุญาตที่จะหมดเวลา อนุญาตให้พวกเขาดาวน์โหลดการอัปเดตและเริ่มต้นด้วยตนเอง การอัปเดตอัตโนมัตินั้นสะดวก แต่บางครั้งผู้ใช้ก็ไม่ชอบความประหลาดใจ

ดูที่เฟรมเวิร์ก Sparkle สำหรับ OS X ซึ่งทำหน้าที่คล้ายกับกลไกการอัปเดตของ Chrome แต่ให้ความคิดเห็นกับผู้ใช้เพื่อให้พวกเขาสามารถข้ามการอัปเดตหรือดำเนินการในภายหลัง ฉันเคยอัปเดตแอปพลิเคชันกับฉันและเปลี่ยนฟังก์ชันการทำงานที่ฉันต้องการเหมือนเดิมดีที่สุดเสมอที่จะถามผู้ใช้อย่างน้อยที่สุด

ฉันชอบความคิดที่ฉลาด แต่เหมาะสมที่จะทำอย่างนั้นมันง่ายและทดสอบได้ดีจริงๆ ณ จุดนี้

ฉันรู้จัก บริษัท ที่ทำสิ่งที่คุณได้อธิบายไปแล้ว (น้อยกว่าที่คุณอธิบายไว้และฉันไม่รู้ว่าพวกเขารับรองความถูกต้องอย่างไร)

ปัญหาที่ใหญ่ที่สุดที่พวกเขามีคือลูกค้าบางรายบล็อกการเข้าถึงอินเทอร์เน็ตจากอุปกรณ์ของพวกเขา นั่นหมายความว่าลูกค้าเหล่านั้นเพิ่งถูกล็อครุ่นที่ติดตั้งไว้ อาจจะไม่เป็นไร ฉันคิดว่าพวกเขากล่าวถึงการเปิดกฎไฟร์วอลล์กับลูกค้าเหล่านั้น คนอื่นเพิ่งอัพเกรดด้วยตนเอง

ถ้าฉันจะทำฉันจะทำตามที่อยู่ IP ดังนั้นเมื่อพวกเขามาดาวน์โหลดที่อยู่ IP ของพวกเขาจะต้องอยู่ในรายการที่อนุญาตเพื่อเชื่อมต่อกับเซิร์ฟเวอร์นั้นมิฉะนั้นพวกเขาไม่สามารถดาวน์โหลดได้ มันแย่มากถ้าพวกเขาไม่มี IP เฉพาะ แต่ไม่น่าเป็นไปได้จากสิ่งที่ดูเหมือนว่าคุณกำลังพูดถึงถ้ามันเป็นเซิร์ฟเวอร์ที่ใช้ถ้ามันใช้สำหรับสถานีงาน คัดลอกผ่านงาน cron หรืออะไรที่มากกว่า ftp และอื่น ๆ สัปดาห์ละครั้งและมีเวิร์กสเตชันดาวน์โหลดจากที่นั่นขึ้นอยู่กับคุณจริงๆ

นี่เป็นวิธีการปรุงรสที่ดี

ข้อผิดพลาดบางประการที่ควรพิจารณา:

• คุณอาจไม่ต้องการที่จะไป 1 เปอร์เซ็นต์, 9 เปอร์เซ็นต์, 90 เปอร์เซ็นต์ ลูกค้าของคุณอาจไม่เหมือนกันซึ่งหมายความว่าคุณอาจต้องการเริ่มเชี่ยวชาญพูดตามภูมิภาคตามประเภทอุปกรณ์ ฯลฯ ซึ่งในกรณีนี้การกระจายโดย 1, 9, 90 เปอร์เซ็นต์ทั่วโลกไม่สมเหตุสมผลอีกต่อไป

• มีพื้นที่เก็บข้อมูลเดียวสำหรับ 90 เปอร์เซ็นต์ของผู้ใช้ของคุณแนะนำฮอตสปอต - เซิร์ฟเวอร์นั้นจะได้รับคำขอจำนวนมากซึ่งหมายความว่ามันจะเป็นครั้งแรกที่ตายในกรณีที่เกิดกระแสไฟจราจรทำให้ผู้ใช้ของคุณ 90% ความซ้ำซ้อนช่วยแน่นอน แต่ที่แนะนำค่าใช้จ่ายโดยรวมมากขึ้น

• คุณอาจมีเวิร์กโฟลว์ที่ฟีเจอร์บางอย่างพร้อมสำหรับการแจกจ่ายถึง 90 เปอร์เซ็นต์ของผู้ใช้ทั้งหมด แต่การอัปเดตทั่วโลกจะทำให้ฟีเจอร์ไม่พร้อมสำหรับการนำไปใช้งาน 90 เปอร์เซ็นต์เพื่อนำไปสู่การผลิตและแนะนำคอขวดในเวิร์กโฟลว์ dev ของคุณ การกระจายแบบคงที่จะไม่สามารถจัดการกับปัญหาเหล่านี้ได้อย่างมีประสิทธิภาพบังคับให้คุณจัดการสิ่งนี้ในระดับแอปพลิเคชัน

วิธีที่ถูกต้องสำหรับการทำเช่นนั้นคือการเก็บสำเนา repos การผลิตหลายชุดไว้บนเซิร์ฟเวอร์ที่แตกต่างกันวาง load balancer ที่สามารถกำหนดค่าได้ด้านหน้าจากนั้นทำการอัพเดต repos การผลิตของคุณอย่างค่อยเป็นค่อยไป กล่าวอีกนัยหนึ่งให้ปฏิบัติต่อ repos ทั้งหมดในที่สุดอยากจะเหมือนกัน แต่กำหนดค่าการรับส่งข้อมูลเพื่อให้เปอร์เซ็นต์ของผู้ใช้ที่อ่านจากเซิร์ฟเวอร์นั้นสามารถเปลี่ยนแปลงได้

ประโยชน์คือคุณสามารถกำหนดค่าการกระจายคำขอที่จะใช้ load balancer ของคุณคุณสามารถปรับขนาดแนวนอนได้ดีขึ้น (เซิร์ฟเวอร์ทั้งหมดของคุณสามารถเริ่มให้บริการ repo เดียวกันตามสัดส่วนถ้าคุณสมบัติทั้งหมดพร้อมสำหรับการนำไปใช้ 100 เปอร์เซ็นต์) และขึ้นอยู่กับว่า เวิร์กโฟลว์ของทีมคือและคุณต้องการการอัปเดตเฉพาะภูมิภาคคุณสามารถอนุญาตให้ฟีเจอร์บางอย่างพร้อมใช้งานได้ทันทีโดยไม่ต้องกังวลเกี่ยวกับฟีเจอร์อื่น ๆ