Introduction
This modules provides the mechanism to integrate with 3rd party Git Providers.
Objective
, activate repositories.
Repositories contain your source code and after you activate them, you can deploy that source code in created environments.
You can also integrate and turn on continuous integration per repo per provider as well as follow on the build logs when code is committed.
Overview
SOAJS integrates with multiple Git Providers such as Github - Bitbutcket & Bitbucket Enterprise ..The modules supports multiple account types: Public - Private & Organizations.. and supports pulling code from both public and private organizations
Once an account has been linked, the list of repositories is fetched and you can activate / deactivate its repositories accordinglythese repositories by specifying the branch.
By default, every new installation of SOAJS dashboard comes equipped with SOAJS's default account and have a set of repositories already activated but not shown:
Each repository contains the code of a ready made SOAJS products. Together,
Altogether these product products are deployed in Dashboard Environment and form the in an Environment (DASHBOARD) forming a cloud of microservices, that allow you need to buildprovision, configure and deploy services, daemons and static content in all the other environments.
Activate and turn CI on Repositories.
Configure Cd on deployed repository service.
manage and operate all other environments.
Other environments contain the code of the product(s) you are building.
How it Works
Git Repositories contain your code that can be categories as one of the 3 options below:
and once activated, the repository gets labeled based on the content inside it.
| Label | Description |
|---|---|
| service | The content of the repository represents a microservice. |
| daemon | The content of the repository represents a daemon. |
| config | The content of the repository represents a configuration that can be attached when deploying source code or resources. |
| static | The content of the repository represents static html files. |
| custom | The content of the repository is unknown or SOAJS was not able to parse it and understand what it represents. |
| multi | The repo contains multiple types from the above options, this type of repo is considered as a parent hosting multiple sub entries. Example: https://github.com/soajs/soajs.examples |
When activating a repository, the Dashboard attempts to load a config.js file from the root level of that repository and parse it to learn what this repository contains.Once a repository is activated and based on what it contains, you will be able to see a new service/daemonSOAJS runs the following algorithm in attempt to understand what the content of the repository represents.
- Look for soa.js at the root level and parse it
- Tag the repo based on the schema found in soa.js
- If the content represents a multi repo, loop inside child array and repeat step 1 and 2
- If soa.js is not found, look for config.js and parse it
- Tag the repo based on the schema found in config.js
- If the content represents a multi repo, loop inside child array and repeat step 1 and 2
- If neither files are found or after parsing any of the two, soajs is not able to understand what the content is about, tag the repository as custom.
Microservice
A microservice is a Restful HTTP server that contains APIs. Click here to see how to build a microservice.If If the repository contains only 1 microservice, then the config.js file should have a schema the schema should be similar to:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
'use strict';
module.exports = {
type: 'service', //type is service
prerequisites: {
cpu: '',
memory: ''
},
serviceVersion: 1,
serviceName: "example03",
serviceGroup: "SOAJS Example Service",
requestTimeout: 30,
requestTimeoutRenewal: 5,
servicePort: 4012,
extKeyRequired: true,
session: true,
oauth:true,
errors: {},
schema: {
//api list
}
}; | ||||||
| Note | ||||||
SOAJS needs the following properties to be static in order to identify it as a service : | ||||||
| Key | Value (example) | |||||
| serviceVersion | 1 | |||||
| serviceName | example03 | SOAJS Example Service | ||||
| servicePort | 4012 |
Daemon
A Daemon is nodeJS script that supplies jobs to be executed in a certain order. Click here to see how to build a daemon.If If the repository contains only 1 daemon, then the config.js file should have a schema the schema should be similar to:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
'use strict';
module.exports = {
'type': 'daemon', //type is daemon
'prerequisites': {
'cpu': '',
'memory': ''
},
'serviceName': 'myDaemon',
'serviceGroup': 'myDaemonGroup',
'servicePort': 4177,
'errors': {
400: 'Mongo Database connection error',
401: 'Error while executing Count Query.',
402: 'Model not found'
},
'schema': {
//job list
}
}; | ||||||
| Note | ||||||
| Key | Value (example) | |||||
| serviceName | myDaemon | |||||
| serviceGroup | myDaemonGroup | servicePort | 4177
Static Content
Static content represents html, css and front end javascript files. If the repository contains only 1 static content, the schema should be similar to:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
'use strict';
module.exports = {
'type': 'static', //type is static
'name': 'myCustomUI'
}; |
Configuration Repo
This type of repo contains configuration files that can be attached via Catalog Recipes and then used when deploying source code and resources in environments. the schema in this case should be similar to:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
'use strict';
module.exports = {
'type': 'config' //type is config
}; |
Multi Repo
A multi repo is a collection of any of the above types.If If the repository contains a multi repo, then the config.js file should have a schema the schema should be similar to:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
"use strict";
module.exports = {
"type":"multi",
"folders": [
"mySrv1/", //service
"myDaemon/", //daemon
"myUI/", //static
content "myOther/", //custom
"mySrv2/myConf" //serviceconfig
]
}; |
| Anchor | ||||
|---|---|---|---|---|
|
Activate
, Configure & turn on Continuous Integration
Activate your repository then click its configuration button, the configuration page opens up showing all the continuous integration providers that are a linked and that you can integrate with for this repository. For each provider, you can see the configuration of the repository and modify the settings as well as monitor the latest build information per branch.
Configuration
This section provides the ability to modify the repo settings at the continuous integration provider.
There is some predefined environment variables related to SOAJS, which are displayed in read only mode. Plus as read only that SOAJS automatically pushes when you click Update Settings.
These variable instruct the provider how to communicate with the DASHBOARD Environment to trigger continuous delivery whenever the build passes after a code commit has been detected.
In addition, you can add some custom variables according to your needs.
| Note |
|---|
You can only configure repositories which are activated, deployed in an environment other than dashboard, dependent to the same git owner and which you have access on git. |
You can check the available CI provider recipe. The list of continuous integration recipes is also present In case you would like to use one of them, simply download it → extract it → add it to in your repository and push it.
According to the repository branch you pick, we will check for a recipe and compare it with the available recipes.
To make CD functional, Download CD script, add it to your repository as well and push it to GIT. In this way, on any change, this script will run and act based on your CD configuration.
If you already have a continuous integration recipe in your repository, SOAJS tries to compare it with the list mentioned above and see if there is a match which helps you identify which repos are using the standardized recipes you created and which have custom recipes in them.
Finally, to trigger continuous deliver, click on the Download CD script at the bottom of the page, extract the zip file and place it in your repository.
This script in conjunction with the predefined environment variables mentioned above act together to trigger the continuous deliver API in the DASHBOARD and provide it with the details about the repository and its content.
The API will take this information and run it through its Release Manager and based on the configuration you provided in Continuous Delivery section, the repository content gets deployed, updated or you only receive an update notification.
Build Information
This section displays details about the latest build information per branch for each repository.
The list contains details about:
- Where did the build happen, and if it passed or failed as well as the build number
- How long did it take to run the build and what time it started.
- The commit message and commit id linking it to the Git account of the repository
- The author that made the commit
- In which environments the code of this repo is deployed and what is the continuous delivery strategy used per environment
- The build log details and the continuous integration recipe configuration that was used with this build
- A link that redirects to the continuous integration interface to see the full history of this repository at the provider level
The content of list informs you what is happening, where and what will be affected whenever there is a code update that is pushed to your repository.
