Here I’m going to document a few DevOps practices & a couple more personal recommendations, particularly related to the source control (Git/GitHub), which we follow.

I work as a Lead DevOps Engineer for one of the biggest financial enterprises, and SOC compliance is of paramount importance. Being SOC compliant and scaling by hundreds or more projects and engineers is nearly impossible without team-wide standard practices & policies.

TL;DR

• Have standard naming convention.
• Follow trunk-based development.
• Always protect the master & development branch.
• PR pipeline to trigger on each Pull Request.
• Ensure each commit message link to Rally/Jira.
• Have a .gitignore file & never commit your dependencies into source control.
• Avoid committing secrets into source control.

Standard Naming Convention

Most importantly, adopting a consistent naming convention across the organization is essential. The first thing I did after joining this team is to develop a web form where you can enter the details of your project. It will spit out the exact naming convention to follow while creating project repository, pipeline job, sonarqube-dashboard, artifactory, last but not least, the cloud-foundry component names & routes.

Keep all your repository name in small letters and have a hyphen (-) as a word separator. It is a personal preference, and you may separate your words with any other character you want except space or tab.

Trunk-based development

We advise trunk-based development to the team while onboarding a green-field project. In trunk-based development, developers always commit to a single branch; typically, the development branch also called the trunk. The idea is to have your master/main branch reflect the last production build. Then we can enable the development branch to be automatically deployed on every commit.

We follow the below branch naming convention

• For all the feature branches, follow the prefix feature/xxx.
• For all the bugfix/defect branches, follow bugfix/defect-#
• For all the hotfix branches, follow hotfix/defect-#

🚧 Protect the master/main & the development branch.

It will ensure no accidental commit/merge to the above branches, and all the changes go through a peer-review process.

PR pipeline

All the changes in the repository should happen through Pull Requests. And each of the PR should trigger a PR pipeline that ensures the build is successful, all the unit tests are passed, and have at least 80% of code coverage.

🔗 Every commit to link to Rally/Jira ticket

It helps in achieving traceability across the development lifecycle. And is the most obvious way to remain compliant, especially for those enterprises operating in the financial sector. As the DevOps Handbook highlights,

“We can generate evidence on-demand to demonstrate that our controls are operating effectively, whether to auditors, assessors, or anyone else working in our value stream.”.

Ex: US12345 fixes the nasty divide by zero exception.
We can easily enforce this at the developer-end with git-hooks.

Another excellent tool I recommend to write informative commit messages & streamline the commit process is Commitizen. You do not need to wait until a git commit hook to run.

📦 Have a .gitignore file & never commit your dependencies into GitHub.

As you have already guessed, the heaviest thing in the universe is nothing but node modules 😝. Keep all the unwanted dependencies, personal configs & IDE generated files in a .gitignore. You can check out here to create a .gitignore file for the tech-stack of your choice.

🔐 Avoid committing credentials/secrets to GitHub

As Twelve-Factor-App methodology highlights,

“A litmus test for whether an app has configs & secrets correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials”.

Inadvertently committing 🗝credentials and other secrets into source control is not a rare case. Few tool recommendations to decouple secrets from source code are git-secrets and Talisman. We’re using Vault, a secret as a service tool for storing & accessing secrets, along with spring cloud-config.

So, these are the core recommendations related to source-control we do highlight while we onboard any apps into the DevOps. I hope that’s helpful!.