CI/CD deployment docs #2389
CI/CD deployment docs #2389
Conversation
Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>
Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>
Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>
| **Continuous Deployment (CD)** refers to the automatic deployment of code changes to the production environment. This is commonly know as "push to deploy" and frees developers from having to manually deploy code changes. | ||
|
|
||
| ## Running tests in CI |
There was a problem hiding this comment.
I wonder if this should be under deployment, since CI is a separate thing from deployment.
Maybe it would be better if we had a part of docs called Testing and then tehre we can have CI part?
There was a problem hiding this comment.
Looking good! This one feels a bi tless claer to me, regarding what should be here. Seems every easy to me to go into too much details, or to not give enough info. Since it is more CI/hosting provider specific than Wasp specific. So I think it is ok to keep this as light as we can.
|
|
||
| TODO: we'll talk about how to e2e test Wasp apps in the CI | ||
| **Continuous Integration (CI)** involves verifying/testing code changes through an automated process whenever code is pushed to the repository. This helps us catch bugs early and make sure that our app works. |
There was a problem hiding this comment.
| **Continuous Integration (CI)** involves verifying/testing code changes through an automated process whenever code is pushed to the repository. This helps us catch bugs early and make sure that our app works. | |
| **Continuous Integration (CI)** involves verifying/testing code changes during development through an automated process whenever code is pushed to the repository. This helps us catch bugs early and make sure that our app works. |
| We'll show you how to run end-to-end tests in CI using the [Github Actions](https://github.com/features/actions) as our CI and the [Playwright](https://playwright.dev/) as our e2e testing framework. | ||
|
|
||
| 1. Check our example app and its e2e tests in the [e2e-tests](https://github.com/wasp-lang/e2e-test-example/tree/main/e2e-tests) directory. |
There was a problem hiding this comment.
Hmmm should this point to release branch? Usually in docs we aim to point at release branch, since we know it is in sycn with the released version of the docs.
| import { expect, test } from "@playwright/test"; | ||
| import { generateRandomUser, logUserIn } from "./utils"; | ||
|
|
||
| const user = generateRandomUser(); | ||
|
|
||
| test.describe("basic user flow test", () => { | ||
| test("log in and add task", async ({ page }) => { | ||
| await logUserIn({ page, user }); | ||
| await expect(page).toHaveURL("/"); | ||
| await expect(page.locator("body")).toContainText("No tasks yet."); | ||
|
|
||
| // Add a task | ||
| await page.fill('input[name="description"]', "First task"); | ||
| await page.click('input:has-text("Create task")'); | ||
| await expect(page.locator("body")).toContainText("First task"); | ||
| }); | ||
| }); | ||
| ``` | ||
| </details> |
There was a problem hiding this comment.
You can probably drop this? It is just a small snippet, and it risks becoming out of date, we have to maintain it, real code is anyway in that example app you linked to.
| - for our server app | ||
| - for our client app | ||
| 4. Notify your deployment provider to deploy the new image. |
There was a problem hiding this comment.
This can depend on their hostirng provider, right? If I am correct some of them have their own registries so this looks more like just a single command, or maybe you just give them a branch with Dockerfile, stuff like that?
Also client app doesn't have to be in Dockerfile.
Also might be worth mentiong here that we provide Dockerfile for the server.
And now that I am writnig all this, sounds to me like this is quite complex and we should instead point them to the part of deployment docs that describes it in details? Maybe just be very simple here, try not to assume much, link to the part with dpeloying Wasp app, and say that they will want to use whatever method their hosting providers reocmmends for CD. And an example deployment of ours, that is cool.
Talks about how users can test their apps in the CI and about packaging their apps in Docker images for CD.