Skip to content

Latest commit

 

History

History
94 lines (69 loc) · 3.1 KB

hb-deployment-integration.org

File metadata and controls

94 lines (69 loc) · 3.1 KB
Raw

Deployment & Integration Handbook

https://img.shields.io/badge/made%20by-Chenla%20Institute-999999.svg?style=flat-square https://img.shields.io/badge/class-docs-56B4E9.svg?style=flat-square https://img.shields.io/badge/type-runbook-0072B2.svg?style=flat-square https://img.shields.io/badge/status-wip-D55E00.svg?style=flat-square https://img.shields.io/badge/licence-MIT%2FCC%20BY--SA%204.0-000000.svg?style=flat-square

Introduction

We have a long ways to go, but at least we have working webhooks :)

Deployment Types

Git post-receive hook

This works very well for personal projects only being worked on by a single developer.

Changes are pushed to the user account on the production server. A git post-receive hook is triggered which builds the site and copies it to document root.

SEE: New Web Site Handbook

Projects should treat master as stable, and use feature branches named after GL# issues.

GitLab Webhook Push Event

This works for very small development teams (1-2 members) where everyone can push to the production server.

Changes are pushed to origin which triggers a webhook that points to a webhook receiver on the production server. The reciever then runs a shell script that builds and deploys the code.

SEE: Webhook Receiver Handbook

Projects should treat master as stable, and use feature branches named after GL# issues.

GitLab Webhook Merge Event

NOTE: This not been implemented yet.

This is for small development teams (2-10 members) where there is a person who must approve changes before they are deployed to the production server.

The production branch on GitLab is protected and a merge request must be created to merge to the branch. After the merge manager reviews and tests the changes, the merge is approved and merged with production. This triggers a Webhook which points to a webhook on the productin server which then runs a script which builds and deploys the code.

Projects should treat master as stable, and use feature branches named after GL# issues. Feature branches are merged into master and after testing, a merge request is create to merge master with production which triggers a webhoo that deploys the site.

GitLab CI, Multi-Stage Test, Build & Deployment

NOTE: This not been implemented yet.

After that we will move to a multi-stage deployment, with a separate staging branch in the repo which will trigger a runner on a staging server which will build and run tests. Then if the tests run will trigger a merge request to merge with the production branch which will trigger a webhook which deploys the app or webpage to the production server.