Knowledge transfer and Product Quality Acceptance

1. Back-end software application

  • Read the documentation
  • Setup development environment on a local machine according to documentation
  • Import project
    • Configure access on SCM (source code management)
    • Get project sources from the repository
  • Assemble Project
    • Follow the documentation and assemble the project locally
  • Run the Project
    • Follow the documentation and run the project locally
  • Run integration tests
    • Follow the documentation and run test locally
  • Monitor Project Activity
    • Follow the documentation and check Project activity
  • Create new feature
    • Follow SDLC to develop a new feature
  • Test new feature
    • Run integration tests
    • Perform regression tests
  • Accept feature
    • Final acceptance activities
  • Deploy new feature
    • Follow the documentation for CI/CD pipelines

 

2. Front-end software application (vue.js)

  • Introduction to project architecture
  • Setup development environment on a local machine
    • Install Node.js 
    • Install Npm
  • Import project
    • Get project sources from the repository
  • Assemble Project
    • Install dependencies
    • Set up developer server proxy in vue.js config
    • Set up a local environment
    • Developer build and local server: run command “npm run dev”
  • Read the API documentation from swagger
  • Create new feature
    • Follow SDLC to develop a new feature
  • Test new feature
    • Follow QA to test a new feature
  • Deploy new feature
    • Follow the documentation for CI/CD pipelines
  • Accept feature
    • Final acceptance activities

 

3. iOS software application

  • Quick start:
    • Checkout /develop branch from the VCS
    • Navigate to the iOS project folder and run “pod install”
    • Open .xcworkspace project file using XCode
    • Each target has 3 configurations: Debug/Release/Sandbox. Each of them could be set up in the “Build Settings->User-Defined” section. 
    • To choose each configuration please follow these steps: “Edit scheme-><you can choose a configuration for run or archive to build scheme >”
    • Connect real device through USB port/WiFi or use the built-in simulator
    • Hit run (app configuration).
  • Current specs:
    • XCode: 12.2 beta 4
    • Pods: 1.10.0
    • Swift: 5.1
  • Сompilation problems may be related to the operating system on which the build is running. 

 

4. Android software application

  • Quick start:
      • Checkout /develop branch from the VCS
      • Import Gradle project using Android Studio
      • Switch to sandboxDebug build variant 
      • There is a default Run\Debug configuration for compiling the project, named ‘app’
      • Connect real device through a USB port or use a built-in emulator
      • Hit run (app configuration) and Gradle build script will merge all libraries and compile apk file
  • Current specs:
      • AndroidStudio: 4.1.1
      • Tools.build:gradle: 4.1.1
      • Gradle Wrapper: gradle-6.5-all.zip
      • Kotlin: 1.4.21
      • sdk.finance.android:core-library: 1.0.83
  • Сompilation problems may be related to the operating system on which the build is running. The version of AndroidStudio may be updated or third-party libraries are out of date
  • Overview: 
      • The project is designed by MVVM architecture.
      • All logic is contained in ViewModel controllers.
      • DI approach is used for instantiation.
      • All API’s are wrapped in UseCases in the separate jar library.
      • Also, the UI binding is partially used in the layout.
      • The project hierarchy is designed with the separation of areas of influence according to the principle of Clean Architecture.
  • Development:
    • To start developing new features please create a separate branch (preferably to use the git-flow approach).
    • Create separate folder using template below and register new component in the core scope:
    • Create DI module “{feature name}”/di/”{Feature name}Module” 
    • Create ViewModel  “{feature name}”/”{Feature name}ViewModel” 
    • Bind controller to the di module:
      •   @Binds
      •   @IntoMap
      •   @ViewModelKey({feature name}ViewModel::class)
      •   abstract fun bind{Feature name}Model(viewModel:{Feature name}ViewModel): ViewModel
  • Create Fragment “{feature name}”/”{Feature name}Fragment”
  • Register both files in UiModule like: 
    • @ContributesAndroidInjector(modules = [(app.ui.{feature name}.di.{feature name}Module::class)])
    • internal abstract fun contribute{feature name}Fragment():{feature name}Fragment
  • In order to code layouts and use binding(i.e. preloader widget , info binding etc.) please provide following root nodes: 
    • <layout
    •     xmlns:android=”http://schemas.android.com/apk/res/android”
    •     xmlns:app=”http://schemas.android.com/apk/res-auto”
    •     xmlns:tools=”http://schemas.android.com/tools”
    •     >
    •   <data>
    •     <import type=”android.view.View”/>
    •     <import type=”app.ui.{feature name}.{feature name}Fragment”/>
    •     <variable
    •         name=”viewModel”
    •         type=”app.ui.{feature name}”.”{Feature name}ViewModel”
    •         />
    •   </data>

 

Component 5. CI/CD on AWS (DevOps scripts)

  • The Developer creates a separate branch from the development branch except for cases when the changes are a hot-fix for the production (in this case master branch must be used as a source branch)
  • When changes are ready, the developer submits the merge request to the original branch that was used in step 1.
  • After creating the merge request, integration tests and security tests are launched. If the tests didn’t pass, the code is returned to the Developer for correction.
  • After tests are done successfully the merge request goes for code review. If the code review didn’t pass, the code is returned to the Developer for correction.
  • The merge request is applied.
  • Deploy to the development server is automatically started.
  • Testing changes by the team. Found errors are sent to the developer for correction.
  • To do a release a merge request from the develop branch to the master branch should be created.
  • Integration and security tests are launched.
  • Merge request goes through code review and merges to master.
  •  Based on the master branch, the project manager to create a pre-production release of the git tag (*-rc\d).
  • After git tag pre-production release is created the pre-release is automatically deployed to the staging server.
  • The team conducts testing. The client gets acquainted with new or revised features. If bugs or errors are found, the code is returned to the Developer for correction.
  • Based on the master branch, the project manager to create a production release of the git tag (.*-release). Important: pre-release and release tag must be created on the same commit.
  • After git tag production release is created the pre-release is automatically deployed to the production server.
  • The team checks the functionality. If a critical error or bug is identified, a hotfix is ​​immediately developed and deployed.

6. Business analyst view: Product knowledge transfer

  1. Platform overview
  • Roles/actors
  • Roles associated operations
  • Wallet engine
  • APIs
  1. Business processes
  • Registration/authorization
  • Onboarding
  • Top-up/withdrawal/transfer
  • Schedule payments
  • POS
  • Vouchers (prepaid)
  • Invoices
  • Currency exchange
  1. Possible integrations
  • Acquirer
  • Bank
  • Card processor
  • KYC
  • Others