คำถามติดแท็ก integration

ฉันกำลังตรวจสอบเทคนิคและกลยุทธ์ในการปรับขนาดการทดสอบการรวมระบบที่เพิ่มขึ้นของเราในผลิตภัณฑ์ปัจจุบันของเราเพื่อให้พวกเขาสามารถ (เป็นมนุษย์) ยังคงเป็นส่วนหนึ่งของการพัฒนาของเราและกระบวนการ CI ที่การทดสอบการรวมกันกว่า 200 ครั้งเราได้ทำเครื่องหมาย 1 ชั่วโมงเพื่อทำการทดสอบเต็มรูปแบบ (บนเครื่องเดสก์ท็อป aa) และสิ่งนี้มีผลกระทบในทางลบต่อความสามารถของนักพัฒนาในการทนต่อการรันทั้งชุด ซึ่งส่งผลต่อแรงจูงใจที่จะต้องมีระเบียบวินัยในการสร้างให้ดี เรารวมการทดสอบ Scenrios สำคัญเท่านั้นด้านหน้าไปด้านหลังและเราใช้สภาพแวดล้อมที่สะท้อนการผลิตที่สร้างขึ้นตั้งแต่เริ่มการทดสอบแต่ละครั้ง เนื่องจากเวลาที่ใช้ในการรันจึงทำให้วนรอบการตอบกลับแย่มากและวงจรที่สิ้นเปลืองจำนวนมากรอให้เครื่องทำการทดสอบเสร็จสิ้นไม่ว่าการทดสอบจะเน้นไปที่ใด ไม่ต้องกังวลกับผลกระทบด้านลบที่มีราคาแพงกว่าต่อการไหลและความก้าวหน้าสติและความยั่งยืน เราคาดว่าจะมีการทดสอบการรวมเพิ่มเป็น 10 เท่าก่อนที่ผลิตภัณฑ์นี้จะเริ่มทำงานช้าลง (ไม่มีความคิดจริง ๆ แต่ก็ไม่รู้สึกเหมือนว่าเรากำลังเริ่มต้นในแง่ของคุณสมบัติเลย) เราต้องคาดหวังอย่างต่อเนื่องว่าจะมีการทดสอบการรวมสองสามร้อยหรือสองสามพันครั้งฉันคิดว่าในบางจุด เพื่อความชัดเจนในการพยายามป้องกันไม่ให้สิ่งนี้กลายเป็นการสนทนาเกี่ยวกับการทดสอบหน่วยกับการทดสอบการรวม (ซึ่งไม่ควรแลกเปลี่ยน) เรากำลังทำการทดสอบทั้งหน่วยด้วย TDD และการทดสอบการรวมในผลิตภัณฑ์นี้ ในความเป็นจริงเราทำการทดสอบการรวมที่เลเยอร์ต่าง ๆ ในสถาปัตยกรรมบริการที่เรามีซึ่งมันสมเหตุสมผลสำหรับเราเนื่องจากเราต้องตรวจสอบตำแหน่งที่เราแนะนำการเปลี่ยนแปลงที่ผิดพลาดเมื่อเปลี่ยนรูปแบบในสถาปัตยกรรมของเราไปยังพื้นที่อื่น ๆ ของ ระบบ. เล็กน้อยเกี่ยวกับสแต็คเทคโนโลยีของเรา ขณะนี้เรากำลังทดสอบสภาพแวดล้อมการจำลอง (CPU และหน่วยความจำมาก) เพื่อทำการทดสอบของเราตั้งแต่ต้นจนจบ ซึ่งประกอบด้วยบริการเว็บ Azure REST ซึ่งแสดงแบ็กเอนด์ noSql (ATS) เรากำลังจำลองสภาพแวดล้อมการผลิตของเราโดยทำงานใน Azure desktop …

21 testing  continuous-integration  integration 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัพเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา บริษัท ที่ฉันทำงานอยู่กำลังประเมินโซลูชันมิดเดิลแวร์สำหรับการวัดการวัดและความปลอดภัยของบริการบนเว็บ ขณะนี้เรากำลังใช้ Enterprise Service Bus (ESB) เพื่อจุดประสงค์นี้ แต่มีผู้บริหารที่ยอดเยี่ยมบางคนตัดสินใจว่าพวกเขาจะปรับใช้ API Management Middleware บางส่วน ฉันค้นคว้าข้อมูลเล็กน้อยเกี่ยวกับโซลูชันการจัดการ API (หรือที่รู้จักว่าเกตเวย์ API) แต่ไม่พบความแตกต่างระหว่างสิ่งเหล่านี้กับ ESB จริง ฉันประเมินเอกสารสีขาวจาก Mule, WSO2, Oracle เป็นต้น แต่คุณสมบัติที่นำเสนอโดยผลิตภัณฑ์ทั้งสองดูเหมือนจะใกล้เคียงกัน คำถามคือสิ่งที่การจัดการ API สามารถทำสิ่งที่ ESB ไม่สามารถทำได้และในทางกลับกัน? สามารถเพิ่มมูลค่าอะไรลงในโครงสร้างพื้นฐานด้านไอทีโดยแทนที่ ESB สำหรับ API เกตเวย์

20 integration  middleware 

ฉันกำลังมองหาคำตอบใน SO หรือที่นี่ แต่ไม่มีผลลัพธ์ใด ๆ นั่นคือเหตุผลที่ฉันจะถามคุณ สมมติว่าฉันมีสองโครงการที่แตกต่างกัน - ตัวอย่างเช่นส่วนของเซิร์ฟเวอร์และส่วนลูกค้าของแอพ ฉันกำลังพัฒนาส่วนของตัวเองในขณะที่เพื่อนของฉันกำลังสร้างส่วนที่สอง แต่ทั้งสองของเราควรจะใช้อินเตอร์เฟซบางอย่างร่วมกันเช่นUserหรือAccountInfoหรือChangableAccount... สิ่งเพื่อให้แน่ใจว่าการทำงานร่วมกัน ตัวอย่างเช่นหากลูกค้าส่งข้อมูลผู้ใช้ไปยังเซิร์ฟเวอร์เซิร์ฟเวอร์ควรทำงานในคลาสเดียวกัน เหมือนกับอินเทอร์เฟซและอื่น ๆ นอกจากนี้หากมีการเปลี่ยนแปลงใด ๆ ในอินเทอร์เฟซทั่วไปโครงการทั้งสองควรปรับรหัสให้เป็นสถานการณ์ใหม่ ทางออกเดียวที่ฉันเห็นในตอนนี้คือการสร้างโครงการพิเศษหนึ่งโครงการซึ่งกำหนดสิ่งทั่วไปทั้งหมดไว้ เราฉันและเพื่อนของฉันควรเพิ่มโครงการนี้เป็นการอ้างอิงไปยังโครงการหลัก (ไคลเอนต์หรือเซิร์ฟเวอร์) โครงการที่ใช้ร่วมกันสามารถจัดการได้โดยระบบควบคุมเวอร์ชันบางระบบดังนั้นเราจึงมีสถานะที่ทันสมัยที่สุดเสมอ คุณจะแนะนำโซลูชันอื่นใดอีก ปัญหาดังกล่าวได้รับการแก้ไขอย่างไรในแอพมืออาชีพ

17 java  dependencies  integration  dependency-management 

เมื่อเร็ว ๆ นี้ฉันได้อ่านรูปแบบการรวมองค์กรของ Hohpe และ Woolf หนังสือของ Thomas Erl บางตัวเกี่ยวกับ SOA และดูวิดีโอและพ็อดแคสต์ต่างๆโดย Udi Dahan และคณะ บน CQRS และระบบขับเคลื่อนเหตุการณ์ ระบบในที่ทำงานของฉันต้องทนทุกข์ทรมานจากการมีเพศสัมพันธ์สูง แม้ว่าแต่ละระบบจะมีฐานข้อมูลเป็นของตนเองในทางทฤษฎี ในทางปฏิบัติหมายความว่ามีฐานข้อมูลขนาดใหญ่หนึ่งระบบที่ใช้ทั้งหมด ตัวอย่างเช่นมีข้อมูลลูกค้าหนึ่งตาราง สิ่งที่ฉันได้อ่านส่วนใหญ่ดูเหมือนว่าจะแนะนำข้อมูลที่ผิดปกติเพื่อให้แต่ละระบบใช้เฉพาะฐานข้อมูลของตน ฉันคิดว่านี่เป็นวิธีหนึ่งในการบังคับใช้ขอบเขตใน SOA - แต่ละบริการควรมีฐานข้อมูลของตัวเอง แต่จากนั้นฉันอ่านสิ่งนี้: /programming/4019902/soa-joining-data-across-multiple-services และมันบอกว่านี่เป็นสิ่งที่ผิดที่ต้องทำ การแยกฐานข้อมูลดูเหมือนจะเป็นวิธีที่ดีในการแยกระบบออก แต่ตอนนี้ฉันสับสนเล็กน้อย นี่เป็นเส้นทางที่ดีใช่ไหม เคยแนะนำหรือไม่ว่าคุณควรแยกฐานข้อมูลบนเปิดบริการ SOA บริบท DDD Bounded แอปพลิเคชัน ฯลฯ

17 soa  integration  cqrs  eai  domain-driven-design 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้มีแนวโน้มที่จะเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา เรากำลังจะจ้างวิศวกรใหม่ 1-2 คนสำหรับทีมซอฟต์แวร์ (ประกอบด้วยนักพัฒนา 3 คน, 1 ผู้ทดสอบ) ขั้นตอนในการรวมเข้ากับทีมคืออะไร? ความคิดของฉันคือ: อ่านเอกสาร (มาตรฐานการเข้ารหัส, เอกสารในวิธีการพัฒนาที่เราใช้) ให้พวกเขาอ่านรหัสที่มีอยู่ มอบหมายงานง่ายๆให้พวกเขา ในตอนท้ายทำให้พวกเขารับผิดชอบส่วนของรหัส เราจะทำอะไรได้อีก โครงการอยู่ในภาคการแพทย์ (ระบบอัลตร้าซาวด์) และจะไปแล้ว 5 ปี เรามีการเผยแพร่เป็นประจำทุกปีและเรากำลังจะเสร็จสิ้นการปล่อยหนึ่งครั้งเมื่อเราต้องการเพิ่มวิศวกร 1-2 คน โครงการอยู่ในขั้นตอนการบำรุงรักษา (การเปลี่ยนรหัสดั้งเดิมรวมถึงการเพิ่มคุณสมบัติใหม่) ทุกอย่างเป็นไปตามกำหนดเวลา (มากหรือน้อย)

12 team  integration 

เรามีใครบางคน (เรียกเขาว่าเท็ด) ที่รับผิดชอบการทดสอบคุณสมบัติใหม่และการแก้ไขข้อบกพร่อง เรากำลังใช้GitและGitHub masterควร / สามารถใช้งานได้เสมอและdevelopmentเป็นสถานที่ที่เรายอมรับ / รวมคุณสมบัติใหม่หรือแก้ไขข้อผิดพลาด แต่หลังจากที่พวกเขาได้รับการทดสอบโดยเท็ด โครงการอยู่ใน PHP ฉันต้องการให้กระบวนการทดสอบเป็นไปตามนี้: ผู้พัฒนาต้องการทำงานกับคุณสมบัติใหม่ (สมมติว่าคุณสมบัติ / ข้อผิดพลาด # 123 เป็นเอกสาร Ted ในตัวติดตามปัญหา) ดังนั้นเขาจึงดึงorigin/developmentไปdevelopmentที่ที่เก็บในเครื่องของเขาและสร้างสาขาใหม่ (สมมติว่าissue-123) จากที่นั่น originเมื่อเขามีความสุขกับการทำงานของเขาเขามุ่งมั่นและผลักดันสาขาใหม่ของเขาไป เท็ดเชื่อมต่อtest.ourproject.com/choose-branchและดูรายการของสาขาoriginและเลือกที่จะเปิดissue-123(มันควรจะทำได้ผ่านหน้าเว็บ) จากนั้นเขาก็test.ourproject.comทำการทดสอบนรกจากเว็บแอปพลิเคชั่น (เขาเป็นคนที่ไร้ความปราณี) และหลังจากกลับมากับนักพัฒนาเขามีความสุขกับคุณสมบัตินี้ เท็ดบอกนักพัฒนาที่ว่าเขาสามารถผสานissue-123เข้าสู่บนdevelopmentorigin ล้างและทำซ้ำ สำหรับขั้นตอนที่สามฉันสามารถแฮ็คสิ่งที่ทำงาน (แสดงและสลับสาขาจากหน้าเฉพาะ) แต่ฉันรู้สึกว่าสิ่งที่ฉันอธิบายไว้เป็นรูปแบบทั่วไปมาก ดังนั้นคำถามของฉันคือ: นี่เป็นเวิร์กโฟลว์ที่ดี / ยั่งยืน / บำรุงรักษาได้สำหรับการแยกหรือไม่ คุณสามารถสำรองคำตอบของคุณโดยอ้างตัวอย่างของโครงการอื่น ๆ ที่ติดตามเวิร์กโฟลว์นี้หรือไม่?

11 testing  git  integration