+1 to using this way to reduce load of integration testing. But I am also interested in what Yangbo mentioned, "apollo is too complex a system for our use case". My doubt is is there any way to reduce this complex, any user guide blog for it?
Best Regards, --- Zen Lin [email protected] Focused on Micro Service and Apache ServiceComb YangYongZheng <[email protected]> 于2018年7月18日周三 上午11:24写道： > Yes, we only need test integration mechanism, not Apollo itself > > > Best Regards! > YangYongZheng > > > -----邮件原件----- > 发件人: Yang Bo [mailto:[email protected]] > 发送时间: 2018年7月18日 11:13 > 收件人: [email protected] > 主题: Re: [DISCUSS]Simplify Dynamic Config (Apollo) Integration Test in Java > Chassis > > For the purpose of testing this is OK. But the real problem here is that > apollo is too complex a system for our use case. > > > On Wed, Jul 18, 2018 at 11:01 AM 郑扬勇 <[email protected]> wrote: > > > Hi all： > > We had integration with Apollo for support dynamic config in Java > > Chassis, our CI will pull up apollo docker containers for test > > (nobodyiam/apollo-quick-start and lijasonvip/apollodb), this step is > > very slow and easy failed. > > I found that we are only use apollo openapi ( > > https://github.com/ctripcorp/apollo/wiki/Apollo%E5%BC%80%E6%94%BE%E5%B > > 9%B3%E5%8F%B0) to get configurations from it, code below : > > > > private static RestTemplate rest = new RestTemplate(); > > ResponseEntity<String> exchange = rest.exchange(composeAPI(), > > HttpMethod.GET, entity, String.class); > > > > It is a general http GET request, so I think we only need start up a > > http server and direct return a default configuration content for this > > url in order to simulate the apollo server, that is enough. > > > > Any thoughts? > > > > Best Regards & Thanks! > > Yangyong Zheng > > > > -- > Best Regards, > Yang. > > > >
