User Tools
tech:devops:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
tech:devops:start [2015/11/23 01:08] rk4n3 |
tech:devops:start [2018/11/11 21:14] (current) rk4n3 |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Software Development and Deployment Topics ====== | + | <typo fs:xx-large; fw:bold>DevOps</typo> |
| + | ====== Trivia of Technique ====== | ||
| + | ==== JWT ==== | ||
| + | === Create a JWT Key === | ||
| + | ''openssl rand -base64 32'' | ||
| - | ===== Revision Control: git ===== | + | ====== Practices & Deployment Topics ====== |
| + | Mature revision control workflow uses some branching conventions combined with some access policies to ensure that work being done in parallel by a number of developers can proceed with a minimum of collision-caused trouble, and with maximum safety. | ||
| - | Our revision control workflow uses some branching conventions combined with some access policies to ensure that work being done in parallel by a number of developers can proceed with a minimum of collision-caused trouble, and with maximum safety. | + | ===== Continuous Integration ===== |
| + | ==== Jenkins ==== | ||
| + | [[tech:devops:jenkins:start|Jenkins topics]] | ||
| + | ==== Maven ==== | ||
| + | [[tech:devops:maven:start|Maven topics]] | ||
| + | ==== Archiva ==== | ||
| + | [[tech:devops:archiva:start|Archiva topics]] | ||
| + | ==== JMeter ==== | ||
| + | [[tech:devops:jmeter:start|JMeter topics]] | ||
| + | ==== Gatling ==== | ||
| + | [[tech:devops:gatling:start|Gatling topics]] | ||
| + | ===== Revision Control: git (self-hosted) ===== | ||
| + | ==== Git Usage ==== | ||
| + | [[tech:devops:git|Basic usage, cheatsheet, tips, and tricks for git]] | ||
| ==== Repositories ==== | ==== Repositories ==== | ||
| - | There are three tiers of repository: | + | In this proposal, there are three tiers of repository: |
| - | * The off-site/archival "vault" repository \\ This repo resides in codehub, and is only read-accessible. No direct changes will be made to this repository. \\ | + | * An off-site/archival "vault" repository \\ This repo resides on a server/service where developers are allowed only read-access. No direct changes will be made to this repository. \\ |
| - | * The central development "shared" repository \\ This repo resides on the development server, and is where all developers will push their changes to. \\ | + | * The central development "shared" repository \\ This repo resides on a development server, and is where all developers will share and acquire changes to/from. \\ |
| * Individual developer "clone" repositories \\ Every developer will have one or more of these, which serve as the "working space" for code changes to be made and committed. \\ | * Individual developer "clone" repositories \\ Every developer will have one or more of these, which serve as the "working space" for code changes to be made and committed. \\ | ||
| - | === Codehub Repository === | + | === Vault Repository === |
| - | Only build/release admins will have write-access to the "vault" repository in codehub. The only route for changes into this repository is a push from the shared development repository. This will only be done per release, by a build/release admin, and can be deferred until all aspects of a release and the associated changes are fully vetted. This repository also serves as an off-site backup. | + | Only build/release admins will have write-access to the "vault" repository. The only route for changes into this repository is a push from the shared development repository. This will only be done per release, by a build/release admin, and can be deferred until all aspects of a release and the associated changes are fully vetted. This repository also serves as an off-site backup. |
| === Central/Shared Development Repository === | === Central/Shared Development Repository === | ||
| - | This is the repository that all developers will clone their individual working repositories from, which means it is also the repository that will receive the pushes of changes from developers. The only direct changes made in this repository will be official release merges to the master branch, performed only by a build/release admin, for the purpose of integrating changes for a release. When a release has been built, tested, and deployed successfully, it can then be pushed to the codehub repository. | + | This is the repository that all developers will clone their individual working repositories from, which means it is also the repository that will receive the pushes of changes from developers. The only direct changes made in this repository will be official release merges to the master branch, performed only by a build/release admin, for the purpose of integrating changes for a release. When a release has been built, tested, and deployed successfully, it can then be pushed to the vault repository. |
| === Individual/Developer Clone Repositories === | === Individual/Developer Clone Repositories === | ||
| Line 33: | Line 51: | ||
| ==== Basic Workflow ==== | ==== Basic Workflow ==== | ||
| - | This would be the highlights of the typical developer change cycle workflow: | + | === Typical developer change cycle workflow: === |
| - | * Developer clones from shared central repository, or updates existing clone with ''git pull'' | + | * Clone from shared central repository, or update existing clone with ''git pull'' |
| * Clone is switched to ''dev'' branch: ''git checkout dev'' | * Clone is switched to ''dev'' branch: ''git checkout dev'' | ||
| * Iterations of change-then-commit cycles in clone working space | * Iterations of change-then-commit cycles in clone working space | ||
| Line 40: | Line 58: | ||
| * Push freshly-resolved merge to the central shared repository | * Push freshly-resolved merge to the central shared repository | ||
| - | The central build cycle workflow: | + | === The central build cycle workflow: === |
| * All developers commit, push, and confirm completion on the ''dev'' branch | * All developers commit, push, and confirm completion on the ''dev'' branch | ||
| * An integration/test release is build from the current ''dev'' branch, and deployed to the central dev environment for testing and verification | * An integration/test release is build from the current ''dev'' branch, and deployed to the central dev environment for testing and verification | ||
| * When the release passes verification, a build/release admin merges the ''dev'' branch to the master branch in the central shared repository, and builds the production release from the master branch | * When the release passes verification, a build/release admin merges the ''dev'' branch to the master branch in the central shared repository, and builds the production release from the master branch | ||
| - | * After the production release is deployed and verified, the codehub repository can be updated with a push from the central shared repository | + | * After the production release is deployed and verified, the vault repository can be updated with a push from the central shared repository |
| + | === Optional developer workflow: === | ||
| + | * Clone from shared central repository, or update existing clone with ''git pull'' | ||
| + | * Clone is switched to ''dev'' branch: ''git checkout dev'' | ||
| + | * Create private branch (named at developer's discretion) and switch to it | ||
| + | * Iterations of change-then-commit cycles in clone working space | ||
| + | * Update clone with ''git pull'' to see others' changes on ''dev'' branch without disturbing private branch | ||
| + | * Selectively merge others' changes from the ''dev'' branch into the private branch | ||
| + | * Further iterations of change-then-commit cycles in clone working space | ||
| + | * Update clone with ''git pull'' | ||
| + | * Switch to ''dev'' branch | ||
| + | * Merge changes from private branch into ''dev'' branch, resolve conflicts, and commit | ||
| + | * Push freshly-resolved merge to the central shared repository | ||
| + | |||
| + | {{ :tech:devops:git-practices-01.png?nolink&640 |}} | ||
| + | |||
| + | ===== Revision Control: github ===== | ||
| + | The [[http://www.github.org|github]] hosting platform operates similarly to the above //self-hosted// scheme, with some differences that makes sense to github's free software community sensibilities. | ||
| + | |||
| + | ==== Details: under construction ==== | ||
| + | |||
| + | ==== New branches created in upstream repo ==== | ||
| + | You may want a new branch, created in upstream repo, populated into your fork of that repo and your local clone(s) of your fork of that repo, so that you can work on the new branch, or at least see it. With GitHub, this isn't as trivial as natively-stored repos. | ||
| + | |||
| + | First, you'll need to make sure your local clone of your repo fork knows about its upstream: | ||
| + | <code>git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git</code> | ||
| + | |||
| + | Then, you'll need to make sure the new upstream branch is pulled into your local clone: | ||
| + | * Ensure your working tree is clean (commit/stash/revert any changes), then, do: \\ ''git fetch upstream'' | ||
| + | * Create and switch to a local version of the new upstream branch //(which is named newbranch in this example)//: \\ ''git checkout -b newbranch upstream/newbranch'' | ||
| + | * When you're ready, push the new branch to origin: \\ ''git push -u origin newbranch'' \\ // The -u switch sets up tracking to the specified remote (in this example, origin) // | ||
| + | ==== Trivia ==== | ||
| + | \\ | ||
| + | \\ | ||
| + | // Links: [[tech:start|Tech Info]] ... [[tech:linux:start|Linux Info]] // \\ | ||
tech/devops/start.1448262506.txt.gz · Last modified: 2015/11/23 01:08 by rk4n3
Page Tools
