https://invisionapp.github.io/kit

https://invisionapp.github.io/kit

kit opensource

Last synced: about 2 months ago
JSON representation

• Host: GitHub
• URL: https://invisionapp.github.io/kit
• Owner: InVisionApp
• License: mit
• Archived: true
• Created: 2016-06-09T15:30:34.000Z (over 8 years ago)
• Default Branch: master
• Last Pushed: 2022-09-15T19:38:00.000Z (about 2 years ago)
• Last Synced: 2024-06-14T03:35:29.418Z (5 months ago)
• Topics: kit, opensource
• Homepage: https://invisionapp.github.io/kit/
• Size: 277 KB
• Stars: 73
• Watchers: 13
• Forks: 5
• Open Issues: 1
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

• awesome-kubernetes - Kit

README

        


  

    

  



# kit

**[DEPRECATED] Thanks for using these packages, but we will no longer support them.**

The `kit` suite is a series of components that when used together can achieve a continuous deployment workflow for countless Kubernetes clusters. They can be used as npm modules to orchestrate your own pipeline or they can be easily integrated into a [Codeship Docker](http://pages.codeship.com/docker) pipeline.

It currently consist of 3 core components:

| Component               | Version           |

| ----------------------- |-------------------|

| [kit-image-deployer (DEPRECATED) ](https://github.com/InVisionApp/kit-image-deployer)      | [![npm version](https://badge.fury.io/js/kit-image-deployer.svg)](https://badge.fury.io/js/kit-image-deployer) |

| [kit-deploymentizer (DEPRECATED) ](https://github.com/InVisionApp/kit-deploymentizer)      | [![npm version](https://badge.fury.io/js/kit-deploymentizer.svg)](https://badge.fury.io/js/kit-deploymentizer)      |

| [kit-deployer (DEPRECATED) ](https://github.com/InVisionApp/kit-deployer)            | [![npm version](https://badge.fury.io/js/kit-deployer.svg)](https://badge.fury.io/js/kit-deployer)      |

## Flow Diagram



  



## Goals

###### 1. Deployment pipeline is simple and therefore easy to maintain**

This pipeline keeps things simple by utilizing a Docker powered pipeline that can used for builds and testing for deployments as well. By doing this, you avoid having to run external services (such as a central service that triggers deployments, Vault or Consul services for configuration management, authentication services, etc) to manage the deployments.

###### 2. Compatible with Codeship’s docker pipeline architecture

Entire workflow uses the power of Codeship's Docker pipeline for builds, testing and deployments.

###### 3. Dev teams handle deployments of their images via their service’s repository

Developers simply open PRs for their code changes where Codeship will run the builds and tests to verify the changes. Once the build passes, the developer merges the PR into "master" (or any other deployable branch) and Codeship runs another build & test to verify and finally commits newly created image tag to the deployments repository where it is then deployed to the cluster via Codeship.

###### 4. Updates to images, environment variables or configurations are automatically and continuously deployed

Whenever a service's code is changed, it goes through it's Codeship pipeline to generate a new image that is tagged and pushed to our registry. The tagged image is then committed to the deployments repository where all cluster configurations are stored which automatically triggers Codeship to generate the new deployment files and deploy them to all our clusters. This keeps the deployment's repository image tags in sync with the appropriate deployed image. Because environment configuration will be reusable across multiple clusters and instances of the application, it makes it incredibly easy to rotate keys by simply updating it in the repository in a single place and the auto deployment takes care of it from there.

###### 5. Be able to handle clusters dynamically being added and removed

Whenever system administrators (or other automated systems) create new clusters, they can add it to the Deployments repository. This will automatically trigger the Codeship deploy process for these clusters and thus any future updates to services and environment variables will get deployed to the new cluster.

###### 6. Support deploying to multiple namespaces within the one cluster

Again this would be configured within the Deployments repository so that the Codeship deploy step will know which namespaces the deployments go to across as many clusters as we desire.

###### 7. Retain audit trail of changes to all deployments across all clusters

Because this process is using git, you have full history of all commits that occur and by whom the commits were made.

###### 8. Ability to easily rollback any changes (images, environment, configurations, etc)

Rolling back is as easy as reverting a commit on the corresponding service repo or the deployments repository which will trigger the Codeship deploy process.

###### 9. High availability as to avoid a single point of failure for deployments

Although automatic deploys will be halted if Github or Codeship were inaccessible, it doesn't mean you can't deploy. As long as you have a mirror of the git repo on Codeship and system administrators have the Codeship AES key, you can manually perform deployments as needed.