Transformation at Techcombank

Credit to our senior leadership, colleagues and partners, we have managed to deliver many great products in past 12 months. I have documented our past achievements in "2020: A Year to Remember and to Forget".

We're Hiring

In this article my intention is to show more details of how we are working and what are progress in order to help you to see if you are interested to join us.

Few of My Colleagues

These are few members of my colleagues who you can reach out to them and ask questions about these how we work, Team Charter, our vision, working environment, my leadership style, current products/projects and more.

• Ngan, Yen, Hang and our leader of TA Veo, these are our awesome Talent Acquisition members.
• Dustin who is leading our DevSecOps initiative and Lily who is our awesome quality team member.
• Soe, Loong Fei, Do, Thang and James who are leading our digial initiatives.
• Duc, Hung, Dzung and Lang are some of our architects that can code. We do not hire architect that do not code ;)
• Thao who is in charge of Learning & Development of Engineering team under Pratima's leadership.
• Lumos, Harry, Tien, Quyen and Tung are some of our backend team.
• Trang, Nam and Linh are some of our frontend team (angular, swift and kotlin).

Roles

These are the roles that we are recruiting actively:

• Senior Web Developer (angular)
• Senior Swift Developer
• Senior Kotlin Developer
• Senior Backend Developer (Spring)
• Test Engineers
• DevSecOps Engineers
• Solution Architects that codes

Training Platform

Each member of technology team is entitled to get access to PluralSight (unfortunately you will need to sign a training bond). Pluralsight helps engineering identify and close skill gaps in critical areas like cloud, security, software development, IT, and data. Pluralsight Skills provides visibility around technology skills and roles you need to develop to maximize existing teams and deliver products faster. You can read more about what is the benefit of using PluralSight individually in here.

This is my own dashboard as of now:

These are some of trophies that I have earned on PluralSight.

As a leader, we can access to an analytical view like following images which help us to strategize our learning and development priorities to align with our business goals.

Engineering

Our DevSecOps

In re-imagining TCB digital channel over the next 5 years Strategy (2021 – 2025) to achieve our market cap goal. DevSecOps—the collaboration of Development (Dev), Security (Sec) and Operations (Ops) teams—is an organizational approach that enables faster development of applications and easier maintenance of existing deployments. By enabling organizations to create stronger bonds between Dev, Sec, Ops and other stakeholders in the company, DevSecOps promotes shorter, more controllable iterations through the adoption of best practices, automation and new tools. DevSecOps is not a technology per se, but it covers everything from the organization to culture, processes and tooling. Initial steps usually include Continuous integration and continuous delivery (CI/CD), real-time monitoring, incident response systems and collaboration platforms.

Our DevSecOps principles are listed below we follow devsecops manifesto:

• Leaning in over always saying “NO”
• Data & Security Science over fear, uncertainty and doubt
• Open Contribution & Collaboration over security-only requirements
• Consumable Security Services with APIs over mandated security controls & paperwork
• Business Driven Security Scores over rubber stamp security
• Red & Blue Team Exploit Testing over relying on scans & theoretical vulnerabilities
• 24x7 Proactive Security Monitoring over reacting after being informed of an incident
• Shared Threat Intelligence over keeping info to ourselves
• Compliance Operations over clipboards & checklists

Our Goals, Ambition & Vision

Our Development Lifecycle

All these tools are fully implemented (apart from DAST/SAST tool which we are in procurement process).

Our Deployment View

Infrastructure as Code & Configuration management are fully automated and provisioned with: Terraform, Puppet roles and modules.

We are already fully on Private Cloud using Kubernetes for Digital Initiatives.

Git, Jenkins, Nexus Pro and SonarQube

Nothing fancy, we use GitLab but very clearn and organized.

DevSecOps Git Workflow and Pipelines

Ground Rules:

1. Feature or bug fix always branch from develop branch.
2. Hotfix always branch from master branch.
3. Merge frequent if your feature or bug fix branch is taking more than 1 day to complete.
4. Example:

git merge origin develop

• When merge request back to develop branch:
• Sonarqube will reject if quality is below configured threshold. 
• Security Scan will be perform after merge to develop and report to Security team.
• For SIT Release:
• Require a release branch. Create a release branch with the following naming convention:

1. release/x.y.z
2. release/1.0.0
3. release/1.0.1

• Merge request to release branch will trigger:
• SonarQube quality scan. If below configured threshold, merge request will be rejected. Jira bug will be raised to fix.
• Security scan, if unacceptable security issue detected, merge request will be rejected. Jira bug will be raised to fix.
• Developer Lead OR Architect to approve the merge request.
• For UAT Release:
• QA and Security need to agree and tag a version. Example:
• X.Y.Z-uat-yymmdd
• 1.0.0-uat-210221
• 1.0.1-uat-210404
• Once tagged, Jenkins will publish to Nexus and deploy to UAT environment.

Naming Convention

Development Release

SIT Release

UAT Release

Production Release

Hotfix Release

Scenario #1 - One Team and One Release

1. One team working on a single release in sequence is ideal with 1 develop branch and 1 release branch.
2. No special naming convention for develop branch.

Scenario #2 - Two Teams and Two Releases in Parallel

1. In the case of 2 teams working on the same project with 2 releases, then use the above model with 2 develop branch and 2 release branch.
2. One of the possible scenario with 2 team on 2 releases in parallel is when 1st release is delayed and 2nd release need to start to ensure no further delay.
3. In this situation, 
4. 1st release develop branch name will still maintain as develop
5. 2nd release develop branch name will be name with a suffix, example: develop-next
6. No change in the naming of the release branch.
7. The principle here. when a release is merge to master, the master branch will merge back to other release's develop branch. For this example, once the release/1.0.0 branch is merged to master branch, the master branch is merge back to the develop branch of the other release.

Scenario #3 - Three Teams, Two Releases in Parallel and one Experimental Release

1. This scenario is similar to 2 teams on 2 releases approach with a 3rd release.
2. In the example above, the 3rd release is an experimental release, hence i name this branch develop-experiment.
3. Same principle applied, once a release is merged to master, the master branch will merge to all the on going releases develop branch.

Our Jenkins Pipelines

• Input/Output:
• Input: Source code, Web/Mobile Application run on Openshift
• Output: Report source code static scan (IBM source scan), report dynamic scan (IBM source scan/Burp suite scan), Test-case corresponding to user-story (Jira), ticket log bug (Jira), and report testing security (excel file).
• Details step security testing
• Step 1: After SonarQube scan complete, Jenkin CI pipeline will trigger the task "create Jira Ticket" to notify the Security team.
• Step 2: Source code Review. The security Team will perform scan source code and verify manually.
• Step 3: At step "Source code Review" Fail (has vulnerability), Security Team will create Jira ticket log issues and assign to Dev.
• Step 4: If step "Source code Review" Pass, Security Team will update the status "Security Pass" for Source code review in Jira ticket.
• Step 5: Jenkin CD pipeline will trigger the task "create Jira Ticket " for notifying the Security team.
• Step 6: Security Team will run DAST test (Dynamic Scan). If DAST step Fail (has vulnerability). Return step 3.
• Step 7: If "DAST" Pass, Security Team will perform manual testing. At step "Manual testing", if Fail (has vulnerability). Return step 3.
• Step 8: If Pass, Security Team will update the status "SECURITY PASS" for this version release on Jira ticket.

Quality Assurance

Objectives

QC team ensure the quality of Retail banking application through some of objectives:

• To prevent defects by evaluate work products such as requirements, user stories, design, and code.
• To check whether the test object is complete and validate if it works as requirement.
• To find defects and failures thus reduce the level of risk of inadequate software quality.
• To provide sufficient information to stakeholders to allow them to make informed decisions.
• To build confidence in the level of quality of the test object.
• To comply with contractual, legal, or regulatory requirements or standards.

QC team focus on 4 main activities:

Working Cadence

Test Levels

Test Tools chains

Test repository with Xray (Jira)

Automation Test 

Performance Test

Test data