List of contents: Development process Build process DevOps process

1. Microservices Development Process at Predix.io
● Presentation prepared by : Constantine Grigel
● Special thanks to: Alexey Tsyryulnikov

2. Development
Process
At Predix.io

3. ● Multiple repositories: One per Microservice
○ Party Microservice
○ Search Microservice
○ Frontend Microservice
○ Backend Microservice
○ Gateway Microservice
● Main Organization Project Repository
Proposed Git processes.

4. Branching
Inspired by: http://nvie.com/posts/a-successful-git-branching-model/

5. Branch descriptions
● Master. The master branch at origin should be familiar to every Git user. Parallel to the master branch,
another branch exists called develop.
● Dev. Primary development branch, where both teams are primarily committing to.
● Release. Release branch supporting preparation of a new production release. It allows minor bug fixes and
preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch,
the develop branch is cleared to receive features for the next big release.
● Hotfix. Hotfix branch is very much like release branch in that it is also meant to prepare for a new production
release, that is unplanned. It arises from the necessity to act immediately upon an undesired state of a live
production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may
be branched off from the corresponding tag on the master branch that marks the production version.
● Feature. Feature branches (or sometimes called topic branches) are used to develop new features for the
upcoming or a distant future release. When starting development of a feature, the target release in which this
feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as
long as the feature is in development, but will eventually be merged back into develop.

6. Branches mapping to Environments
Git branches: Environments:
Promotion

7. Decentralized, but centralized
Each developer pulls and
pushes to origin.
But besides the centralized
push-pull relationships, each
developer may also pull
changes from other peers to
form sub teams.

8. Pull VS Push Requests
● Dev branch - Nobody cares
● Pull Requests:
Release, Master, Hotfixes, Features

9. Build Process
At Predix.io

10. Gradle as a build standard

11. Code Versioning
● Version Structure: "${branchName}." + "${major}." + "${minor}." +
"{revisionNumber}"gi
○ major / minor - manually controlled
○ branchName / revisionNumber - automatically retrieved at compile
time
● Automatic enforcement at compile time
○ Signed manifest within WAR files
○ Artifactory
● Unified REST API to get service version
● Frontend should be able to display all the versions of all
the underlying services & itself

12. Naming convention for Predix:
Predix service instances & Applications
● Problem
Service instance & application names should be unique
across the whole Predix
● Approach
○ ${service_instace_name}-${env_name}
○ ${app_name}-${env_name}
○ In future we might need to add ${version} into
application name to allow multiple completely
different versions

13. DevOps Process
At Predix.io

14. Jenkins: Structure
● Everything is Pipeline
● Correspond to environments that are implicitly mapped
to git branches.
● Jenkins separate Jobs:
○ Build for commit triggers
○ Green Blue Deployment
○ Continuous Integration
○ Continuous Delivery
○ Continuous Deployment

15. Jenkins: Notifications
Proposed notification schema:
● Success build-job:
○ Committer
○ Release engineer
● Fail build-job:
○ Committer
○ Release engineer
○ Team lead and Scrum master

16. Build and Testing Tools:
● Testing tools:
○ Junit
○ Karma
○ Spring Boot Starter Test
● Build tools:
○ Maven
○ Gradle
○ Grunt/Gulp

17. Artifactory
Usage:
● Store common 3rdParty libraries, jars, etc.
● Production artifacts (war’s, etc.) from
"master" branch.

18. Artifactory
Artifact Versioning:
● Version Structure:
“${jobName}”.+”${environmentName}”.+”${buildNumber}”. + ”${versionNumber}”
● All of the above variables passed as parameters between jobs in
the build pipeline.
● Separate branches created on Artifactory to store multiple
version of the build artifacts.
● Using REST API's of Artifactory tool, retrieving the metadata of
the artifacts to enable seamless deployment process.

19. Code Quality
● Quality gates are defined on SonarQube to check for quality
of Code.
● Developers run local Sonar tests before committing the
code to VCS.
● CI tool is integrated with Sonar. Build jobs would not
succeed if code quality does not meet the thresholds
defined on Quality Gates.
● Offers reports on duplicated code, code quality, unit tests,
code complexity, code coverage.
● Integrate with build tools: Maven, Gradle, etc.
● Integrate with different IDE for local Code quality tests.

20. Predix Spaces & Organizations
● Spaces:
○ Mapping of predix spaces concept to
environments: one environment - one
space.
○ Reason: Access considerations.
● Organizations:
○ Stage & Production environments shall
exist in a separate “Organization”

21. Open Questions?