Numbered Posted October 6, 2017 Share Posted October 6, 2017 This ability will be very useful for OPS team (and for dev's too). I think it is not very hard to develop. We can do this themselves. But our implementation must be supported by us at every IPS update and it will be very painful. What this improvement must do: install app/plugin update app/plugin (just with incoming argv with path to gz / xml file) execute well all inside setup/update parts enable/disable app/plugin or apps module That's it. I think it will be not good only for us. It can open a lot of 3rd_party IPS hosters, which can add personal 'approved' list of apps/plugins, which can their clients install simply. There are a lot of good thing, which will open with that ability. I can write much of them, but i think it is not necessary. Anybody can think their usable situations with that. As one more example - we can do CI for IPS. On some app/plugin commit trigger it can autobuild via Teamcity (or any other) and do a lot of autotests. This will improve quality and waste time for doing that with hands. Or we can simply build simular IPS instance as they exist on a lot of production configuration (with app1, app3, plugin16 and plugin17) - and check any needed problems. Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.