Teamcity Automated Testing
You set up teamcity automated testing by linking source repos to build steps. The server watches for code changes and sends test jobs to build agents. Engineering teams often give those agents broad database keys to run integration checks. When permissions are too wide, a single test script can alter shared data. Broad roles also expose sensitive records inside build logs. How teamcity automated testing works The build server sits at the center of your test workflow. It polls your source cont
Automated Penetration Testing: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up teamcity automated testing by linking source repos to build steps. The server watches for code changes and sends test jobs to build agents. Engineering teams often give those agents broad database keys to run integration checks. When permissions are too wide, a single test script can alter shared data. Broad roles also expose sensitive records inside build logs.
How teamcity automated testing works
The build server sits at the center of your test workflow. It polls your source control system or listens for webhook events. When a developer pushes code, the server adds a job to the queue. It then picks an idle build agent that matches the job requirements.
The agent pulls the latest code into a local work folder. Next, it runs the unit and integration test steps in order. As tests run, the agent streams output back to the central server. The server parses these logs to count passed and failed checks.
Integration tests often need to talk to outside databases or cloud services. Teams store the needed secrets inside project variables on the server. When a job starts, the server sends those secrets to the agent. The agent injects them into the local test process as runtime variables. Once the run finishes, the agent wipes temporary files and waits again.
What native build controls solve and what they miss
Built-in project roles control which team members can edit build steps. You can lock down who views secret variables in the server user interface. The server also scrubs known secret values from the text of build logs. This stops developers from reading raw database passwords on the results page.
Still, these native controls only govern the setup phase before a build starts. Once the agent has the database key, the server cannot filter queries. A flawed test script can still run a drop table command by mistake. Native controls decide who starts a job, not what commands run in flight.
Automated Penetration Testing: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Test suites also pull real rows from staging databases to check app logic. If staging holds customer emails or card numbers, failed assertions print them out. The log scrubber hides the database password, yet it misses leaked customer data. Masking rules that rewrite emails and phone numbers in query results prevent this leak. Teams need statement-level checks to stop bad queries and mask sensitive fields.
Managing test database access at scale
Many teams share one database user across all build agents for speed. When fifty agents run tests at once, database logs show one single identity. If a bad query locks a table, you cannot trace the specific build.
Tying each test run to a distinct identity fixes this audit gap. You should also strip drop and truncate rights from the test role. Read checks and safe writes keep shared test databases stable for everyone. Clear audit logs let you link every query back to its build job.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do build agents handle secret keys during test runs?
The central server stores secret keys at the project level. It sends them to the build agent memory only when a job starts. The server then scrubs those exact strings from the final build log.
Why do integration tests leak sensitive data into build logs?
Integration tests often query staging databases that hold real customer records. When a test fails, the runner prints the full data object for debugging. Native log scrubbers only hide setup secrets, not emails or phone numbers.
How can teams stop test scripts from breaking shared databases?
Teams should remove drop and alter rights from the test database role. You can also check SQL commands in flight to block destructive statements. This keeps shared test tables safe when a script has a bug.