Introduction

This modules provides the mechanism to integrate with 3rd party Git Providers, 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 ... 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 these 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.

Altogether these products are deployed in an Environment (DASHBOARD) forming a cloud of microservices, that allow you to provision, 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 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, SOAJS 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
1. Tag the repo based on the schema found in soa.js
2. 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
1. Tag the repo based on the schema found in config.js
2. 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 the repository contains only 1 microservice, the schema should be similar to:

Config Example for a microservice

'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
	}
};

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 the repository contains only 1 daemon, the schema should be similar to:

Config Example for a daemon

'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
	}
};

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:

Config Example for static content

'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:

Config Example for configuration repo

'use strict';


module.exports = {
	'type': 'config'			//type is config
};

Multi Repo

A multi repo is a collection of any of the above types. If the repository contains a multi repo, the schema should be similar to:

Config Example for a multi repo

"use strict";

module.exports = {
   "type":"multi",
   "folders": [
      "mySrv1/", 	//service 
      "myDaemon/", 	//daemon
      "myUI/", 		//static
      "myOther/",	//custom
	  "myConf"		//config
   ]
};

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 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.

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 in your repository and push.

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.

Browser not supported