คำถามติดแท็ก configuration-management

ฉันใช้ไฟล์JSONเพื่อกำหนดค่าแอปพลิเคชันของฉันเสมอ ฉันเริ่มใช้พวกเขาตั้งแต่ตอนที่ฉันเขียนโค้ด Java จำนวนมากและตอนนี้ฉันทำงานเป็นหลักเกี่ยวกับการพัฒนา Python ด้านเซิร์ฟเวอร์และวิทยาศาสตร์ข้อมูลและฉันไม่แน่ใจว่าJSONเป็นวิธีที่เหมาะสมที่จะไปอีกต่อไป ฉันเห็น Celery ใช้ไฟล์ Python ที่แท้จริงเพื่อกำหนดค่า ตอนแรกฉันสงสัยเกี่ยวกับมัน แต่แนวคิดของการใช้โครงสร้างข้อมูล Python ง่าย ๆ สำหรับการกำหนดค่าเริ่มที่จะเพิ่มขึ้น ข้อดีบางประการ: โครงสร้างข้อมูลจะเหมือนกับที่ฉันเขียนตามปกติดังนั้นฉันไม่จำเป็นต้องเปลี่ยนกรอบความคิด IDE ของฉัน (PyCharm) เข้าใจการเชื่อมต่อระหว่างการกำหนดค่าและรหัส Ctrl+ Bทำให้สามารถข้ามไปมาระหว่างการกำหนดค่าและรหัสได้อย่างง่ายดาย ฉันไม่ต้องการที่จะทำงานกับที่ไม่จำเป็น IMO เข้มงวดJSON ฉันกำลังดูคุณสองคำพูดไม่มีเครื่องหมายจุลภาคต่อท้ายและไม่มีความคิดเห็น ฉันสามารถเขียนการกำหนดค่าการทดสอบในแอปพลิเคชันที่ฉันกำลังทำงานอยู่จากนั้นจึงย้ายพวกเขาไปยังไฟล์กำหนดค่าโดยไม่ต้องทำการแปลงใด ๆ และการแยกวิเคราะห์ JSON เป็นไปได้ที่จะทำสคริปต์ง่าย ๆ ในไฟล์กำหนดค่าถ้าจำเป็นจริงๆ (แม้ว่าสิ่งนี้ควรมี จำกัด มาก) ดังนั้นคำถามของฉันคือถ้าฉันสลับฉันจะยิงตัวเองในเท้าได้อย่างไร ไม่มีผู้ใช้ที่ไม่มีทักษะจะใช้ไฟล์กำหนดค่า การเปลี่ยนแปลงใด ๆ ที่เกิดขึ้นกับไฟล์การกำหนดค่าปัจจุบันมีความมุ่งมั่นที่จะใช้ Git และถูกนำไปใช้กับเซิร์ฟเวอร์ของเราซึ่งเป็นส่วนหนึ่งของการปรับใช้อย่างต่อเนื่อง ไม่มีการเปลี่ยนแปลงการกำหนดค่าด้วยตนเองเว้นแต่จะมีเหตุฉุกเฉินหรืออยู่ระหว่างการพัฒนา (ฉันเคยพิจารณาYAMLแต่มีบางอย่างเกี่ยวกับมันทำให้ฉันรำคาญดังนั้นสำหรับตอนนี้มันอยู่นอกโต๊ะอเมริกัน)

72 python  json  configuration  configuration-management  python-3.x 

ทีมของฉันใช้ Team Foundation Server สำหรับการควบคุมแหล่งที่มาและวันนี้ฉันแก้ไขข้อบกพร่องและแอปพลิเคชันทดสอบควันก่อนที่ฉันจะตรวจสอบ แต่ฉันลืมที่จะแสดงความคิดเห็นรหัสบางอย่าง (รหัสนี้ทำให้ UI แปลกเล็กน้อย) ฉันต้องการทราบวิธีปฏิบัติที่ดีก่อนที่จะตรวจสอบรหัสใน - ฉันไม่ต้องการทำผิดประเภทนี้อีกครั้ง

47 version-control  team-foundation-server  configuration-management 

ส่วนใหญ่ฉันเก็บการกำหนดค่าแอปพลิเคชันการพัฒนาในไดเรกทอรีรากของโครงการเช่นนี้ app |-- config.json แต่นั่นไม่ได้เป็นวิธีที่ดีที่สุดเนื่องจากการกำหนดค่านี้จะถูกเก็บไว้ในระบบควบคุมเวอร์ชัน - อาจส่งผลให้เกิดการรั่วไหลของชื่อผู้ใช้รหัสผ่านและข้อมูลที่ละเอียดอ่อนอื่น ๆ คู่มือแนะนำแอพ 12 Factorแนะนำให้วางไฟล์กำหนดค่าโดยรวมและใช้ตัวแปรสภาพแวดล้อมสำหรับการตั้งค่า: ... เก็บ config ในตัวแปรสภาพแวดล้อม Env vars สามารถเปลี่ยนแปลงได้ง่ายระหว่าง Deploys โดยไม่ต้องเปลี่ยนรหัสใด ๆ ต่างจากไฟล์ปรับแต่งมีโอกาสน้อยที่จะถูกตรวจสอบลงในรหัสซื้อคืนโดยไม่ได้ตั้งใจ และแตกต่างจากไฟล์ปรับแต่งที่กำหนดเองหรือกลไกการกำหนดค่าอื่น ๆ เช่นคุณสมบัติระบบ Java พวกเขาเป็นมาตรฐานภาษาและระบบปฏิบัติการไม่เชื่อเรื่องพระเจ้า ฟังดูดีสำหรับฉันจริง ๆ แต่ร้านใดร้านหนึ่งพูดว่าตัวแปรสภาพแวดล้อมโดยไม่ตรวจสอบสิ่งเหล่านั้นลงในการควบคุมแหล่งที่มา? และเครื่องมือใดที่ฉันสามารถใช้เพื่อส่งตัวแปรเหล่านั้นไปยังแอป สามารถมีตัวเลือกการกำหนดค่าได้หลายสิบตัวและพิมพ์ด้วยมือทุกครั้งที่คุณเปิดแอปไม่ดี - ดังนั้นจึงต้องเก็บไว้ในไฟล์บางประเภท ไฟล์ดังกล่าวจะจบลงในการควบคุมแหล่งและเรากลับไปที่ที่เราเริ่ม มีวิธีจัดการตัวเลือกการกำหนดค่าที่ยอมรับกันโดยทั่วไปหรือไม่ซึ่งไม่มีความเสี่ยงในการจัดเก็บการกำหนดค่าท้องถิ่นในการควบคุมแหล่งที่มา?

38 architecture  configuration  configuration-management 

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

36 version-control  configuration-management 

ในช่วงสามปีที่ผ่านมาที่ฉันทำงานเป็นนักพัฒนาฉันได้เห็นตัวอย่างมากมายที่ผู้คนใช้คำสั่งสวิตช์เพื่อกำหนดเส้นทาง (ทั้งในส่วนหลังและส่วนหน้า) สำหรับ URL ด้านล่างเป็นตัวอย่างของสิ่งนี้: ตัวอย่างด้านหลัง (C #): public static string getHost(EnvironmentEnum environment){ var path = String.Empty; switch (environment) { case EnvironmentEnum.dev: path = "http://localhost:55793/"; break; case EnvironmentEnum.uat: path = "http://dev.yourpath.com/"; break; case EnvironmentEnum.production: path = "http://yourpath.com/"; break; } return path; } ตัวอย่างหน้า (JavaScript): (function () { if (window.location.host.indexOf("localhost") !== …

32 programming-languages  programming-practices  configuration-management  routing 

ฉันรู้ว่านี่เป็นคำถามพื้นฐานมาก หากมีใครสามารถตลกฉันและบอกฉันว่าพวกเขาจะจัดการกับเรื่องนี้ฉันจะยิ่งใหญ่ ฉันตัดสินใจที่จะโพสต์สิ่งนี้เพราะฉันกำลังจะติดตั้ง SynchToy เพื่อแก้ไขปัญหาด้านล่างและฉันรู้สึกไม่เป็นมืออาชีพเล็กน้อยเมื่อใช้ "ของเล่น" แต่ฉันไม่คิดว่าจะดีไปกว่านี้ หลายครั้งที่ฉันพบว่าเมื่อฉันอยู่ในสถานการณ์นี้ฉันพลาดวิธีที่ชัดเจนในการทำสิ่งต่าง ๆ - มาจากการเป็นนักพัฒนาเพียงคนเดียวใน บริษัท แอปพลิเคชันเว็บ ASP.NET ที่พัฒนาบนคอมพิวเตอร์ของฉันในที่ทำงาน โซลูชันมี 2 โครงการ: เว็บไซต์ (ไฟล์) WebsiteLib (C # / dll) ใช้ที่เก็บ Git นำไปใช้งานบนเว็บเซิร์ฟเวอร์ GoGrid 2008R2 การใช้งาน: ทำการเปลี่ยนแปลงรหัส กดเพื่อ Git รีโมตเดสก์ท็อปไปยังเซิร์ฟเวอร์ ดึงจาก Git เขียนทับไฟล์สดด้วยการลาก / วางด้วย windows explorer ในขั้นตอนที่ 5 ฉันลบไฟล์ทั้งหมดออกจากรูทเว็บไซต์ .. นี่เป็นสิ่งที่ไม่ควรทำ นั่นเป็นเหตุผลที่ฉันกำลังจะติดตั้ง SynchToy ... …

21 web-development  deployment  websites  release-management  configuration-management 

ฉันต้องการบันทึกการกำหนดค่าของโครงการซึ่งรวมถึง ขนาดหน้าจอ ตำแหน่งหน้าจอ เส้นทางโฟลเดอร์ การตั้งค่าผู้ใช้และอื่น ๆ สถานที่มาตรฐานที่คุณสามารถบันทึกสิ่งเหล่านี้คือค่าการกำหนดค่าคือ: Registry ไฟล์ INI ไฟล์ส่วนบุคคล (เช่น * .cfg) คุณเลือกระหว่างสถานที่เหล่านี้อย่างไร นอกจากนี้ยังมีข้อดีและข้อเสียของการใช้ใด ๆ ของพวกเขา?

19 windows  microsoft  configuration-management  persistence 

ฉันเป็นแฟนตัวยงของ DI / IOC มันเป็นเรื่องที่ยอดเยี่ยมสำหรับการจัดการ / การแยกตัวออกจากการพึ่งพาอย่างหนักและทำให้ชีวิตง่ายขึ้นเล็กน้อย อย่างไรก็ตามฉันมีด้ามจับเล็ก ๆ กับมันซึ่งฉันไม่แน่ใจว่าจะแก้ปัญหาได้อย่างไร แนวคิดพื้นฐานใน DI / IOC คือเมื่อวัตถุถูกสร้างอินสแตนซ์การอ้างอิงทั้งหมดจะถูกเติมไว้ล่วงหน้าภายใน Constructor อย่างไรก็ตาม IMHO มีพารามิเตอร์หลายประเภทสำหรับตัวสร้าง (โดยเฉพาะเมื่อวัตถุของคุณไม่เปลี่ยนรูป) การพึ่งพา (วัตถุที่จำเป็นสำหรับวัตถุของคุณในการทำงาน) การกำหนดค่า (ข้อมูลเกี่ยวกับสภาพแวดล้อมที่จำเป็นในการทำงาน) พารามิเตอร์ (ข้อมูลที่ใช้งานได้) ฉันพบว่า IOC ทำงานได้ดีกับการอ้างอิง แต่ฉันยังคงพยายามหาวิธีที่ดีที่สุดในการจัดการกับอีกสองคน อย่างไรก็ตามเนื่องจากตัวสร้างถูกเรียกใช้เพื่อให้เรียกใช้งานโดยคอนเทนเนอร์ IOC ดูเหมือนว่าฉันต้องวางรายการเหล่านี้ลงในคอนเทนเนอร์ IOC ฉันต้องการทราบว่ากลยุทธ์ / รูปแบบการจ้างงานของผู้คนและข้อดีและข้อเสียที่พบ NB ฉันรู้ว่านี่เป็นคำถามที่เป็นอัตนัยและได้พยายามทำให้เป็นคำถามแบบอัตนัย "ดี" ตามแนวทางของ SE

18 design-patterns  configuration-management  inversion-of-control 

ฉันยังเป็นผู้ใช้โค่นล้มคนหนึ่งที่พยายามให้ความรู้แก่ตัวเองอีกครั้งในการควบคุมเวอร์ชันแบบกระจาย เมื่อใช้การโค่นล้มฉันเป็นแฟนตัวยงของวิธีการย่อยโครงการและกับอดีตนายจ้างส่วนใหญ่ของฉันเราจะจัดโครงสร้างสาขาที่เก็บของเรา แท็ก & ลำต้นดังนี้: branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk ภายในต้นไม้ต้นกำเนิดจริงเราจะใช้โครงสร้างคล้ายกันดังต่อไปนี้ (src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | …

16 mercurial  organization  continuous-integration  svn  configuration-management 

ลองนึกภาพระบบที่มีเซิร์ฟเวอร์จำนวนมาก แต่ละรายการมีการตั้งค่าจำนวนมาก: บางอย่างเฉพาะกับเซิร์ฟเวอร์ เฉพาะบางภูมิภาค บางคนพบเห็นได้ทั่วทุกคน บางทีคุณอาจมีการจัดกลุ่มแบบกำหนดเองบางอย่างเช่นกลุ่มเซิร์ฟเวอร์นี้มีไว้สำหรับอ่านเท่านั้น เป็นต้น การปฏิบัติปัจจุบันที่ฉันมีอยู่ในใจเป็นโครงสร้างที่เรียบง่ายพร้อมความสามารถที่เหนือกว่า ให้ใช้เซิร์ฟเวอร์ของ Google เพื่อเป็นตัวอย่าง แต่ละรายการมีรายการการตั้งค่าที่จะโหลด ตัวอย่างเช่นเซิร์ฟเวอร์ลอนดอนอาจมี: rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.propertiesฯลฯ ที่แต่ละไฟล์มีชุดของคุณสมบัติและลำดับการโหลดช่วยให้คุณสามารถแทนที่คุณสมบัติได้ยิ่งคุณไปได้ไกลเท่าไหร่ ตัวอย่างเช่น: rootsettings.propertiesอาจมีaccessible=falseค่าเริ่มต้น แต่อยู่เหนือsearchengine.propertiesด้วยaccessible=true ปัญหาที่ฉันมีกับโครงสร้างนี้คือมันง่ายมากที่จะออกจากการควบคุม มันไม่ได้มีโครงสร้างเลยหมายความว่าคุณสามารถกำหนดคุณสมบัติใด ๆ ได้ทุกระดับและหลายรายการอาจล้าสมัย นอกจากนี้การเปลี่ยนระดับกลางจะเป็นไปไม่ได้เมื่อเครือข่ายโตขึ้นเนื่องจากตอนนี้คุณส่งผลกระทบต่อเซิร์ฟเวอร์จำนวนมาก ท้ายสุด แต่ไม่ท้ายสุดแต่ละอินสแตนซ์แต่ละรายการอาจต้องการคุณสมบัติพิเศษ 1 รายการซึ่งหมายความว่าแผนผังของคุณจะจบลงด้วยการกำหนดค่าสำหรับเซิร์ฟเวอร์แต่ละเครื่องอย่างไรก็ตามมันจึงไม่ใช่โซลูชันที่ดีที่สุด ฉันจะขอขอบคุณอย่างมากหากคุณมีข้อเสนอแนะ / แนวคิดเกี่ยวกับสถาปัตยกรรมการจัดการการกำหนดค่าที่ดีขึ้น

15 configuration  configuration-management  properties 

ฉันต้องการทราบวิธีการจัดการโครงการขนาดใหญ่ที่มีส่วนประกอบจำนวนมากพร้อมระบบการจัดการการควบคุมเวอร์ชัน ในโครงการปัจจุบันของฉันมี 4 ส่วนหลัก เว็บ เซิร์ฟเวอร์ คอนโซลผู้ดูแลระบบ เวที ส่วนของเว็บและเซิร์ฟเวอร์ใช้ 2 ไลบรารีที่ฉันเขียน โดยรวมมีที่เก็บ 5 git และที่เก็บข้อมูล 1 แห่ง สคริปต์บิลด์โปรเจ็กต์อยู่ในที่เก็บแพล็ตฟอร์ม มันทำให้กระบวนการสร้างทั้งหมดเป็นไปโดยอัตโนมัติ ปัญหาคือเมื่อฉันเพิ่มคุณสมบัติใหม่ที่มีผลต่อองค์ประกอบหลายอย่างฉันต้องสร้างสาขาสำหรับแต่ละ repo ที่ได้รับผลกระทบ ใช้งานคุณสมบัติ รวมมันกลับมา ความรู้สึกของฉันคือ "มีอะไรผิดปกติ" ดังนั้นฉันจึงควรสร้าง repo เดียวและวางองค์ประกอบทั้งหมดที่นั่น? ฉันคิดว่าการแตกกิ่งจะง่ายกว่าในกรณีนั้น หรือฉันเพิ่งจะทำสิ่งที่ฉันกำลังทำอยู่ตอนนี้ ในกรณีนั้นฉันจะแก้ปัญหานี้ในการสร้างสาขาในแต่ละที่เก็บได้อย่างไร

13 version-control  branching  configuration-management  merging 

ฉันกำลังเขียนเชลล์สคริปต์ด้วยตัวแปรบางตัวที่ควรกำหนดค่าโดยผู้ใช้ จะมีโปรแกรมติดตั้งสำหรับดาวน์โหลดและกำหนดค่าสคริปต์โดยอาจถามคำถามหลายข้อ สคริปต์ที่เป็นปัญหานั้นมุ่งเป้าไปที่ผู้พัฒนารายอื่น สิ่งนี้สามารถนำไปใช้ได้หลายวิธี: ใช้ตัวยึดตำแหน่งในสคริปต์และใช้sedเพื่อแทนที่ในระหว่างการติดตั้ง (สิ่งนี้: /programming/415677/how-to-replace-placeholders-in-a-text-file ) ข้อดี: คำจำกัดความของตัวแปรทั้งหมดมีอยู่ในสคริปต์ ง่ายในการดาวน์โหลดสคริปต์ด้วยตนเองและกำหนดค่าตัวแปรสำหรับผู้ใช้ที่ต้องการตัวแก้ไขมากกว่าตัวติดตั้ง ข้อด้อย: มันยากที่จะกำหนดค่าตัวแปรใหม่ผ่านตัวติดตั้งเมื่อมีอยู่ นอกจากว่าฉันจะสร้าง regexp ที่ซับซ้อนมากขึ้นซึ่งจะมีแนวโน้มที่จะเกิดข้อผิดพลาด ใช้ไฟล์ configโดยทั่วไปแล้วเชลล์สคริปต์อื่นที่มีการมอบหมายและใช้sourceเพื่อรวมไฟล์นั้น (และอาจวางไว้ใน~/.scriptname? สคริปต์หลักถูกคัดลอกไปยัง/usr/local/bin) ข้อดี: ง่ายต่อการกำหนดค่าสคริปต์ใหม่ สามารถเพิ่มพารามิเตอร์สำหรับการทำเช่นนั้นได้จากสคริปต์หลัก (อาจเป็นไปได้ในโซลูชันแรกเช่นกัน แต่การแก้ไขสคริปต์จากตัวเองไม่ได้ฟังดูเหมือนเป็นความคิดที่ดีมาก) ข้อด้อย: สคริปต์นี้ขึ้นอยู่กับสองไฟล์และผู้ใช้จำเป็นต้องเรียกใช้โปรแกรมติดตั้งสำหรับไฟล์การกำหนดค่าที่จะสร้าง สิ่งนี้สามารถแก้ไขได้โดยการสร้างไฟล์ปรับแต่งอัตโนมัติหากไม่มีอยู่ แต่การค้นหาไฟล์กำหนดค่าภายนอกจะยังคงเป็นเรื่องยุ่งยากสำหรับผู้ใช้ที่ต้องการดาวน์โหลดสคริปต์แก้ไขและดำเนินการกับมัน นอกจากนี้ยังมีตัวเลือกเล็กน้อยเกี่ยวกับวิธีการจัดการการกำหนดค่าโดยผู้ใช้หลังการติดตั้ง: คอมไพล์เช่น $ myscript config server.host example.org $ myscript config server.proxypath / home / johndoe / proxy $ myscript config server.httppath …

13 configuration  configuration-management  shell  bash 

ฉันต้องการถามสมาชิกของชุมชนเกี่ยวกับบทบาทของเครื่องมือจัดการการกำหนดค่าตามที่คุณเห็น ฉันไม่ได้ถามว่าการจัดการการกำหนดค่าคืออะไรตราบใดที่มันถูกถามมาก่อน สิ่งที่ฉันต้องรู้คือ: คุณคิดว่างานใดที่เครื่องมือจัดการการกำหนดค่าควรทำงาน (หรือทำงาน) ในทีมของคุณ อะไรคือความรับผิดชอบหลักของเครื่องมือจัดการการกำหนดค่า ความรับผิดชอบรอง / สำรองของเครื่องมือจัดการการกำหนดค่าคืออะไร เครื่องมือจัดการการกำหนดค่าต้องรับผิดชอบกระบวนการพัฒนาในโครงการ / บริษัท หรือไม่หรือเขาควรได้รับแจ้งว่าต้องทำอย่างไร? อะไรคือความสัมพันธ์ระหว่างเครื่องมือจัดการการกำหนดค่า, ตัวจัดการการสร้าง, ตัวจัดการการเผยแพร่, วิศวกรการปรับใช้, บทบาทวิศวกร CI? ไม่เหมือนกันทั้งหมด - การจัดการการกำหนดค่า บางทีการจัดการการกำหนดค่าเป็นคำซ้ำซ้อนและหัวหน้าฝ่ายเทคนิค / ทีมควรทำงานที่เกี่ยวข้องทั้งหมดแทนหรือไม่ มันจะดีมากถ้าคุณสามารถแบ่งปันวิสัยทัศน์และประสบการณ์ของคุณ

11 team  teamwork  configuration-management  role 

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

10 architecture  scrum  code-quality  configuration-management 

เมื่อฉันคิดถึงการกำหนดค่าซอฟต์แวร์ฉันคิดถึงไฟล์ที่อ่านโดยรันไทม์ - ไฟล์ที่กล่าวนั้นจะมีสิ่งต่าง ๆ เช่นพอร์ตที่เซิร์ฟเวอร์อาจใช้ไม่ว่าจะใช้การเข้ารหัสและเส้นทางของทรัพยากรต่างๆ เมื่อครั้งแรกที่ฉันเจอ "การจัดการการกำหนดค่าซอฟต์แวร์" ฉันคิดว่ามันหมายถึงการจัดการไฟล์การตั้งค่าเท่านั้น แต่ฉันก็ตระหนักได้อย่างรวดเร็วว่าเครื่องมือ SCM ไม่เพียง แต่เกี่ยวกับไฟล์การกำหนดค่าเท่านั้น แต่ยังรวมถึงรหัสซอฟต์แวร์ เหตุใดเราจึงใช้คำว่า "การจัดการการกำหนดค่าซอฟต์แวร์" "การจัดการซอฟต์แวร์" จะไม่ครอบคลุมมากกว่านี้ใช่ไหม หรือความเข้าใจของฉันเกี่ยวกับสิ่งที่ถือว่า "ขาด" คืออะไร?

9 terminology  configuration-management