[almighty] Adhoc stack instance for PR code builds

[Max Rydahl Andersen]

> My current thinking is is that we deploy this PR against latest-master
> of everything else. eg. a PR for 'core' would deploy against last
> deployed api and db. Similarly the PR for core would deploy with the
> last good UI and db etc ; but each time, the entire stack is brought
> up as an app, and exposed under its own set of hostnames.[1]

sounds reasonable.

> Since the PR can come from different services, we would need to map
> that via the hostname for clarity eg: core-pr25.<qdn> or ui-pr40.<qdn> 
> e
> tc

+1

> Two primary concerns at this point are :
> 1) it will almost always be a blank db.
> 2) it will be had to have a api change be visible in sync with a
> proposed UI PR.
>
> for (1) the easy route is to do a db dump from demo.db and load that
> into the db brought up for the instance. However, given that this
> brings with it the risk of exposing otherwise-private or privileged
> info, we should never really do that. The middle ground between
> no-data and all-the-data is to have a test dataset. Is this something
> we can do ? if so, we can workout the mechanics of storing it and
> loading/validating it.

I would say we would *have* to be able to load the system with test 
data.
Any system I worked on that had it became so much better by it.

> Given the present dataset live at demo.a.i, generating this test data
> might just be a case of dumping the present dataset into sql and
> checking it into the git repos.

Yes, keep it simple.

> for (2) the solution will likely be in finding a way to parse and
> establish the cross services PR relationship via the github comments.
> However, given the complexity in that, and given that the actual CD
> pipeline for the service as a while will need to be atomic - I propose
> that the PR test stages also be atomic. If a UI function needs core
> functionality, it should be built, tested and deployed via core first
> then exercised via the UI.

I think that is what we would have to do for now.

I wonder if the way to handle the cross-cutting PR's is to instead of 
having Core and UI
in separate repos is to have them together and then split repos based on 
micro service vertical slices
rather than horizontal slices ?

its also one of the tenants of 12factor.net 
(https://12factor.net/codebase) that I think makes a lot of sense
for our kind of app(s).

With this much less magic needed IMO. WDYT ?

/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160910/c023b705/attachment.htm>