search

homeroom-live / homeroom

Live streaming for education.
0 stars 0 forks source link

CI integration #11

Open maticzav opened 6 years ago

maticzav commented 6 years ago

TODO

We should have a very flexible CI integration.

idea

Perfectly we would have a Github worker or something similar which would post URL of staging deployment under the PR. Once we are sure everything is ok we click deploy under PR and everything gets deployed to production servers.

stages

  1. development
  2. staging
  3. production

staging

production

maticzav commented 6 years ago

Streaming setup during staging.

hoodsy commented 6 years ago

@maticzav love the idea section, going to work on setting up CircleCI to only deploy when a folder changes (e.g. www has changes, etc)

UI – staging.homeroom.live API – staging-api.homeroom.live Stream – staging-stream.homeroom.live

Secrets are managed with now, e.g. staging-stripe-secret

maticzav commented 6 years ago

I think we better forget staging-. now by default creates a unique url. I think we could use this as an entry point and paste it in the PR every time changes happen. The only question I have is whether staging should have a separate database from the production one or not?

hoodsy commented 6 years ago

Ive been aliasing now urls to subdomains (e.g. staging-) so that we have a consistent location for the staging app... For example if the API changes and the UI doesn't, we would have to update the UI if it depends on a unique API url.

I think staging should have a separate DB. With Prisma I was using different stages

On Wed, Aug 1, 2018, 1:21 PM Matic Zavadlal notifications@github.com wrote:

I think we better forget staging-. now by default creates a unique url. I think we could use this as an entry point and paste it in the PR every time changes happen. The only question I have is whether staging should have a separate database from the production one or not?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/homeroom-live/homeroom/issues/11#issuecomment-409653404, or mute the thread https://github.com/notifications/unsubscribe-auth/AEQruncFaBZXlQFoceHLJLADJObRPPobks5uMeOXgaJpZM4VDxZG .

maticzav commented 6 years ago

I am not sure I understand the first point; thanks for the second part. I agree we should separate the two if nothing else for the security's sake.

Back to the first point; I think we should update the entire fleet every time we stage. Once changes go to production, staging should be "deleted" - moved to production. Therefore, I don't think we can update only one part of our fleet and unique urls make more sense. Maybe you could explain your point of view?

hoodsy commented 6 years ago

I guess I don't see the value in re-deploying pieces of the application that haven't changed, e.g. the api if the ui is changing.

Ultimately, I really care about:

  1. 0 downtime deploys
  2. A simple release process for dev, staging, and production

With these 2 we should be able to ship quickly and confidently – I don't care too much of the implementation details.

With that said, being able to go to staging.homeroom.live is a convenient shortcut imo. Otherwise, anytime you want to see a change, you have to hunt down the most recent URL.

maticzav commented 6 years ago

Ok, let's figure this out now. I'll explain my thinking and all the benefits we gain with my approach, and afterwards, please do respond to my points and list yours as well.

The deployment cycle consists of three phases. development, staging and production. Right now, we used a shared server for development, but we'll change that before the official release.

Why we want this? development and staging both represent a united chunk of the deployment process - the one that is only visible to us, the developers of Homeroom. Because we want to make sure our code solely relies on the logic and has no side effects caused by data, I believe it is at most important to always start from the clean database. Clean database means that we start from the empty database, or we take a seed from which we spring.

I prefer the second option mainly due to the reason that we don't have to manually insert data to run tests. Even more importantly we gain an enclosed system for testing - just like in an experiment. This is crucial for maintaining scalability and quality testing.

Let me get back to the initial point. We will need seed. Therefore, there's a great benefit to using a local development server rather than using a shared one. The first benefit is that we all start from the same point, we don't overlap each other with data, and most importantly we don't rely on the network during development which helps us understand week points of app performance.

Since we need a clean database when we enter staging, we'll be redeploying entire suite regardless. Luckily, now only publishes new deploy if we made changes to the code. Because of this, we don't have to worry about redeploying unused parts. The wiring should happen on its own.

Using generated URLs instead of aliasing every time has a few advantages. Starting with the fact that our app is still rather small, we want to make sure we'll be able to work on separate branches without overlapping each other in the future. If we're going to support tests across branches though, we cannot go alias to one endpoint as this would mean we could delete the previous deploy which is still relevant. Also, now made it surprisingly easy to push from "staging" to production by aliasing the deployment. To me, this feels like killing two birds with one stone and most importantly decreases code complexity.

Please, tell me what your stands on this are. I am not sure I understand what you mean with "simple release process" for example. Could you try explaining what you mean with this?

Besides that, there'll be no need of searching for the URL. Each PR should automatically get a URL, and we'll know where to find it.

hoodsy commented 6 years ago

Let me get back to the initial point. We will need seed. Therefore, there's a great benefit to using a local development server rather than using a shared one. The first benefit is that we all start from the same point, we don't overlap each other with data, and most importantly we don't rely on the network during development which helps us understand week points of app performance.

💯 On board at this point. Having realistic seed data will help us uncover all types of UI and interaction bugs as well. Not to mention we save time having to manually create a bunch of data.

Using generated URLs instead of aliasing every time has a few advantages. Starting with the fact that our app is still rather small, we want to make sure we'll be able to work on separate branches without overlapping each other in the future. If we're going to support tests across branches though, we cannot go alias to one endpoint as this would mean we could delete the previous deploy which is still relevant. Also, now made it surprisingly easy to push from "staging" to production by aliasing the deployment. To me, this feels like killing two birds with one stone and most importantly decreases code complexity.

Wouldn't a deployment queue eliminate any kind of branch testing issues? We could queue up a number of small changes in a day, and each subsequent change has to pass the full suite of tests before being automatically merged in and deployed.

Please, tell me what your stands on this are. I am not sure I understand what you mean with "simple release process" for example. Could you try explaining what you mean with this?

My priority is a simple and intuitive developer experience. It sounds like we are both after that, so I'm happy to give this a shot.

My criteria for a simple release process? A new developer on the team could release code into production in the first week at Homeroom. Not like this would be some huge contribution – simply the fact they would be able to navigate the code, docs, and release process with confidence to be able to get something out the door. I realize this is broader than simply our release process, but I think it's something to strive for.

hoodsy commented 6 years ago

Additional thought – we should probably host our own Prisma server instead of using Prisma Cloud so we have full control.

maticzav commented 6 years ago

Don't know if that's the best thing to do, honestly. Why do you think we should host it on our own?

hoodsy commented 6 years ago

So that we have full control of the server – any outages are of our own doing and under our control to fix. We can't afford to have multi day outages when we launch, I think we need more control

maticzav commented 6 years ago

I see your point. Honestly, I have to think about the idea a bit more. The most obvious downside of having our server is scalability. There's a high chance we crash on high traffic. Besides that, we could get immediate support if our customers or finances suffered.

As I said, I think we should find the upsides and downsides of both options before we make a conclusion.