A different take on Continuous Integration and Deployment
Encapsulate all of your projects' CI/CD needs into a portable ad-hoc Docker agent.
Execute build/push/deploy and other CI/CD commands using simple one-liners.
Can work for any build tool and any deployment tool. Includes all relevant environment variables and CLI tools.
- Commands: build, push, deploy, cicd, pipeline, promote, ...
- CLIs: hub (github), kubectl, helm, slack, maven, go, dotnet, jira, aws, azure, gcloud, jfrog, ...
- Features: github, kubernetes, aws, java, go, dotnet, ...
WIP / POC / Looking for design partners
Given your project's sources, the first command init creates both the ad-hoc nodevops scripts and Docker agents.
The project's sources and your environment are inspected, language and features are detected, and a customized Docker agent is built accordingly.
The Docker agent is based on alpine, contains the relevant build tools and CLIs, captures the required environment variables, and is portable and executable by any machine - either developers' or CI servers.
From this point, you can use the nodevops script to execute CI/CD commands for this specific project, such as build, push, deploy. The cicd command creates a github webhook, listens to pull requests and comments, and executes pipeline or other commands when required.
It is very easy to extend the project with any build/deploy tool - by adding a Dockerfile snippet (for building the customized Docker agent), and few Shell script lines (for commands execution).
For example, Golang project sources with Dockerfile for packaging, environment variables set for GITHUB_TOKEN, and a defined .kube context - the generated Docker agent will contain Golang and Docker to execute build, together with the environment needed to execute cicd gitops commands with github, and kubernetes for deploy.
Another example, Java project sources with Maven pom.xml and Dockerfile for packaging, environment for GITHUB_TOKEN, DOCKER_REGISTRY and Artifactory context defined - the generated Docker agent will contain Java and Maven to execute build, push and pull artifact into Artifactory and Docker image into the Docker registy, as well as cicd using Github gitops.
Generate nodevops script and Docker agent:
docker run -it -v $PWD:/workspace nodevops/agent init
./nodevops init <project-name> [features]
Execute nodevops build-push-deploy and other commands:
./nodevops build [release]
./nodevops push <release>
./nodevops deploy <release>
Execute CI/CD pipelines using github webhook, adnanh-webhook and ngrok:
./nodevops cicd start <project-name>
./nodevops cicd logs
./nodevops cicd stop
The nodevops script can be commited into the different branches - master, develop and feature - each with optionally slight modifications to reflect the git branching/environment requirements. For example, in the master branch we might want to have continuous deployment to a canary production cluster, and in the develop or feature branches we might want to use different clusters and deployment tools.
Specifically, the pipeline command (practically the Shell script which runs after merging pull request), can also have different variations depending on the branch/environment. We can run different build tasks for master and develop branches, use different notifications (slack or email), and execute different set of tests.
Another point is how to run the operations. One option is using the nodevops script and Docker agents from within your CI server. There is no need to deploy or provision the CI servers with the required tools.
Another option is to use a dedicated kubernetes cluster in order to deploy nodevops command into it. In this scenario, there is no need for CI server and workers, and the deployed Docker agents actually act as an encapsulated build workers.
UI is not in the scope of this project and is orthogonal, but there are several alternatives to get feedback on the running operations and build/deploy status.
As for security, one approach would be to inject tokens and secrets from the running host and user, rather than encapsulating it into the Docker agent.
The nodevops Shell script contains two sections - CI/CD definitions as environment variables and running the Docker agent.
The definitions are captured and prompted in the init command step, based on the optional [features] parameters and the host's environment variables and context, and can be further edited manually.
#!/bin/sh
set -e
# project variables
export PROJECT_NAME=getting-started
export BUILD_TYPE="go docker"
export PUSH_TYPE=docker
export DEPLOY_TYPE=docker
export OPS_TYPE=github
export GITHUB_URL=github.com
export GITHUB_API=https://api.github.com
export GITHUB_USER=noodevops
export DOCKER_REGISTRY=localhost:5000
IMAGE=nodevops/getting-started-agent
...
# run docker agent
docker run ... $VOLUMES $ENV_VARS $IMAGE $@The project is in POC status, and might be WIP. Feel free to contact, fork or send pull requests.
And although I hate licencing (and douchebags in general), for the time being -
Copyright [2019] [Ron Mamo]
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.