I’m documenting some DevOps practices and personal recommendations we follow, especially around source control with Git and GitHub.

Working as a Lead DevOps Engineer at one of the biggest financial enterprises, SOC compliance is absolutely critical. Staying SOC compliant while scaling hundreds of projects and engineers? That’s nearly impossible without consistent team-wide practices and policies.

TL;DR

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

Standard Naming Convention

The most important thing? Adopting consistent naming conventions across your entire organization. The first thing I did after joining this team was developing a web form where you enter your project details, and it spits out the exact naming convention to follow for repository names, pipeline jobs, SonarQube dashboards, Artifactory, and cloud-foundry component names & routes.

Keep all repository names in lowercase with hyphens (-) as word separators. This is my personal preference – you can use any character you want except spaces or tabs.

Trunk-based development

We recommend trunk-based development when onboarding greenfield projects. In trunk-based development, developers commit to a single branch – typically the develop branch, also called the trunk. The idea is simple: your main branch reflects the last production build, while the develop branch gets automatically deployed with every commit.

We follow these branch naming conventions:

• Feature branches: prefix with feature/xxx
• Bugfix/defect branches: use bugfix/defect-#
• Hotfix branches: use hotfix/defect-#

🚧 Protect the master/main & the development branch.

This prevents accidental commits or merges to critical branches and ensures all changes go through peer review.

PR pipeline

All repository changes should happen through Pull Requests. Each PR should trigger a pipeline that ensures the build succeeds, all unit tests pass, and you maintain at least 80% code coverage.

🔗 Link Every Commit to Rally/Jira Tickets

This achieves traceability across the development lifecycle and is the most straightforward way to stay compliant, especially for financial sector enterprises. 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.
You can easily enforce this at the developer level 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.

📦 Use .gitignore & Never Commit Dependencies

The heaviest thing in the universe? node_modules 😝. Keep all unwanted dependencies, personal configs, and IDE-generated files in a .gitignore. Check out gitignore.io to create a .gitignore file for your specific tech stack.

🔐 Keep Credentials Out of 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”.

Accidentally committing 🗝credentials and secrets into source control happens more often than you’d think. I recommend tools like git-secrets and Talisman to decouple secrets from source code. We use Vault as a secret-as-a-service tool for storing and accessing secrets, along with Spring Cloud Config.

Wrapping Up

These are the core source control recommendations we highlight when onboarding apps into DevOps. Following these practices has helped us maintain compliance while scaling rapidly across hundreds of projects.

The key takeaway? Consistency beats perfection. Start with these fundamentals, and you’ll build a solid foundation for DevOps at scale.