You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/pages/articles/deployment.mdx
+3-42Lines changed: 3 additions & 42 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,50 +12,11 @@ Follow the steps in the **Render Initial Blueprint Instance** section to sync it
12
12
13
13
## Git Flow
14
14
15
-
CI/CD using GitHub Actions deploy code updates to the **development** or **production** environments following this [simplified version of Git Flow](https://youtu.be/cV-9KszXEyw?feature=shared&t=845).
15
+
CI/CD using GitHub Actions deploy code updates to the **development** or **production** environments following this [simplified version of Git Flow](https://youtu.be/cV-9KszXEyw?feature=shared&t=845). Refer to the [Git Flow](/post-installation/git-flow) page for more information about this process.
**(Optional)** Before proceeding, create a GitHub Issue describing the new feature, bug fix or task that you'll develop. This tracks the details of the incoming updates.
21
-
22
-
<Steps>
23
-
24
-
### Create a feature branch
25
-
26
-
- Create a **feature branch** branching out from the **dev branch**
27
-
28
-
> If a GitHub Issue describes this feature, name the branch with the GitHub Issue number eg., `feat/acaptutorials-12` (Issue #12)
29
-
30
-
```sh
31
-
git checkout dev
32
-
git checkout -b feat/acaptutorials-12
33
-
34
-
# Using other branch names
35
-
# git checkout -b awesome-update
36
-
```
37
-
38
-
- This isolates new work (feature, bug fix, or task) so it doesn't destabilize the shared development branch.
39
-
40
-
### Merge the feature branch back to dev
41
-
42
-
- Once the feature is complete and reviewed via a **Pull Request (PR)**, it's merged back into **dev**.
43
-
- Approving a PR to the dev branch (or pushing updates directly to the dev branch) triggers a deployment to the **development** (Firebase Hosting, Render and, [Vercel](/articles/deployment-vercel) (if available)) environment.
44
-
- It allows testing the feature with other in-progress features in an integrated (development) environment.
45
-
- Delete the feature branch afterward to keep the repository clean.
46
-
47
-
### Promote dev to master
17
+
<br />
48
18
49
-
- When the **dev branch** has accumulated stable, tested features, create a Pull Request (PR) to **master**
50
-
- The master branch always reflects the code that's safe to release to production.
51
-
52
-
### Tag a release
53
-
54
-
- Tag and version a release from the **master branch** (e.g., v1.0.0).
55
-
- This creates an immutable snapshot of the code that corresponds to a specific release.
56
-
- It also triggers a deployment to the **production** (GitHub Pages, Render and, [Vercel](/articles/deployment-vercel) (if available)) environment.
These tutorials contain additional post-installation instructions after initially setting up the client and server apps in the [Installation](/installation) section.
5
+
These tutorials contain additional post-installation instructions and guidelines after initially setting up the client and server apps in the [Installation](/installation) section.
This page **summarizes the simplified version of Git Flow** branching strategy from the [ACAP video tutorials](https://youtu.be/cV-9KszXEyw?feature=shared&t=845) when developing new features, bug fixes or tasks.
6
+
7
+
CI/CD using GitHub Actions deploy code updates to the **development** or **production** environments on certain triggers (eg., merging PRs to the dev branch or creating new Releases).
**(Optional)** Before proceeding, create a GitHub Issue describing the new feature, bug fix or task that you'll develop. This tracks and organizes the details of the incoming updates.
15
+
16
+
<Steps>
17
+
18
+
### Create a feature branch
19
+
20
+
- Create a **feature branch** branching out from the **dev branch**
21
+
22
+
> If a GitHub Issue describes this feature, name the branch with the GitHub Issue number eg., `feat/acaptutorials-12` (Issue #12)
23
+
24
+
```sh
25
+
git checkout dev
26
+
git checkout -b feat/acaptutorials-12
27
+
28
+
# Using other branch names
29
+
# git checkout -b awesome-update
30
+
```
31
+
32
+
- This isolates new work (feature, bug fix, or task) so it doesn't destabilize the shared development branch.
33
+
34
+
### Merge the feature branch back to dev
35
+
36
+
- Once the feature is complete and reviewed via a **Pull Request (PR)**, it's merged back into **dev**.
37
+
- Approving a PR to the dev branch (or pushing updates directly to the dev branch) triggers a deployment to the **development** (Firebase Hosting, Render and, [Vercel](/articles/deployment-vercel) (if available)) environment.
38
+
- It allows testing the feature with other in-progress features in an integrated (development) environment.
39
+
- Delete the feature branch afterward to keep the repository clean.
40
+
41
+
### Promote dev to master
42
+
43
+
- When the **dev branch** has accumulated stable, tested features, create a Pull Request (PR) to **master**
44
+
- The master branch always reflects the code that's safe to release to production.
45
+
46
+
### Tag a release
47
+
48
+
- Tag and version a release from the **master branch** (e.g., v1.0.0).
49
+
- This creates an immutable snapshot of the code that corresponds to a specific release.
50
+
- It also triggers a deployment to the **production** (GitHub Pages, Render and, [Vercel](/articles/deployment-vercel) (if available)) environment.
0 commit comments