Hello DEV community 👋,

My name is Hasan and I am a software engineer. For a very long time, I have been observing fellow QA engineers suffer from repetitive QA processes and whole teams struggle from deep learning curves of really bloated test managements tools like Xray and Zephyr. I was one of them and I finally built Testream (took me a while though 🙂).

What I wanted to fix:

• Too much setup and too many layers to learn
• Manual test cases eat away QA efforts to build automation
• Poor visibility between test execution and project tracking
• Painful release sign offs while collecting test results
• Invoices that hit harder than flaky tests on release day 🫢

What Testream offers:

• Code-first test management
• Test results from actual real test runs (codebase/CI/CD)
• Native reporters for popular test frameworks
• Free Jira app integration
• No per-seat pricing model, open to whole team

Please claim your free API key and give it a go! Would really appreciate your feedback on the product and onboarding. 🙏

Website: https://testream.app
Documentation: https://lnkd.in/g_jmySVX
Testream Service Space: https://lnkd.in/gFJHRu2t
Jira App: https://lnkd.in/gHQV6tWB

SQL(Structured Query Language) is a powerful tool to search through large amounts of data and return specific information for analysis. Learning SQL is crucial for anyone aspiring to be a data analyst, data engineer, or data scientist, and helpful in many other fields such as web development or marketing.

SQL Joins

JOINS in SQL are commands which are used to combine rows from two or more tables, based on a related column between those tables. They are predominantly used when a user is trying to extract data from tables which have one-to-many or many-to-many relationships between them.

There are mainly four types of joins that you need to understand. They are:

• (INNER) JOIN
• LEFT (OUTER) JOIN
• RIGHT (OUTER) JOIN
• FULL (OUTER) JOIN

INNER JOIN

INNER JOIN is used to retrieve rows where matching values exist in both tables. It helps in:

• Combining records based on a related column.
• Returning only matching rows from both tables.
• Excluding non-matching data from the result set.
• Ensuring accurate data relationships between tables.

Syntax:

SELECT left_table.id, left_table.left_val, right_table.right_val
FROM left_table
INNER JOIN right_table
ON left_table.id = right_table.id;

LEFT JOIN

LEFT JOIN is used to retrieve all rows from the left table and matching rows from the right table. It helps in:

• Returning all records from the left table.
• Showing matching data from the right table.
• Displaying NULL values where no match exists in the right table.
• Performing outer joins, also known as LEFT OUTER JOIN.

Syntax:

SELECT left_table.id, left_table.left_val, right_table.right_val
FROM left_table
LEFT JOIN right_table
ON left_table.id = right_table.id;

RIGHT JOIN

RIGHT JOIN is used to retrieve all rows from the right table and the matching rows from the left table. It helps in:

• Returning all records from the right-side table.
• Showing matching data from the left-side table.
• Displaying NULL values where no match exists in the left table.
• Performing outer joins, also known as RIGHT OUTER JOIN.

Syntax:

SELECT left_table.id, left_table.left_val, right_table.right_val
FROM left_table 
RIGHT JOIN right_tale
ON left_table.id = right_table.id;

FULL JOIN

FULL JOIN is used to combine the results of both LEFT JOIN and RIGHT JOIN. It helps in:

• Returning all rows from both tables.
• Showing matching records from each table.
• Displaying NULL values where no match exists in either table.
• Providing complete data from both sides of the join.

Syntax:

SELECT left_table.id, left_table.left_val, right_table.right_val
FROM left_table 
FULL JOIN right_tale
ON left_table.id = right_table.id; 

Core Insights

SQL joins are fundamental for relational data modeling, enabling the combination of rows from multiple tables based on defined relationships, typically via primary and foreign keys.

Proper join selection directly affects result cardinality, null propagation, and business logic interpretation. Performance considerations include indexing join columns, minimizing unnecessary joins and understanding join order in execution plans.

Key takeaways are that joins operationalize relational integrity, drive multi-table analytics and must be designed carefully to avoid duplication, unintended filtering or performance degradation especially in high-volume transactional or analytical databases.

SQL Window Functions

A window function in SQL is a type of function that performs a calculation across a specific set of rows (the ‘window’ in question), defined by an OVER() clause.

Window functions use values from one or multiple rows to return a value for each row, which makes them different from traditional aggregate functions, which return a single value for multiple rows.

Similar to aggregate function GROUP BY, a window function performs calculations across multiple rows. Unlike aggregate functions, a window function does not group rows into one single row.

Key components of SQL window functions

The syntax for window functions is as follows:

SELECT column_1, column_2, column_3, function()
OVER (PARTITION BY partition_expression ORDER BY order_expression) as output_column_name
FROM table_name

In this syntax:

• The SELECT clause defines the columns you want to select from the table_name table.
• The function() is the window function you want to use.
• The OVER clause defines the partitioning and ordering of rows in the window.
• The PARTITION BY clause divides rows into partitions based on the specified partition_expression; if not specified, the result set will be treated as a single partition.
• The ORDER BY clause uses the specified order_expression to define the order in which rows will be processed within each partition; if not specified, rows will be processed in an undefined order.
• Finally, output_column_name is the name of your output column.

These are the key SQL window function components. One more thing worth mentioning is that window functions are applied after the processing of WHERE, GROUP BY, and HAVING clauses. This means you can use the output of your window functions in subsequent clauses of your queries.

The OVER() clause

The OVER() clause in SQL is essentially the core of window functions. It determines the partitioning and ordering of a rowset before the associated window function is applied.
The OVER() clause can be applied with functions to compute aggregated values such as moving averages, running totals, cumulative aggregates, or top N per group results.

The PARTITION BY clause

The PARTITION BY clause is used to partition the rows of a table into groups. This comes in handy when dealing with large datasets that need to be split into smaller parts, which are easier to manage.
PARTITION BY is always used inside the OVER() clause; if it is omitted, the entire table is treated as a single partition.

The ORDER BY clause

The ORDER BY determines the order of rows within a partition; if it is omitted, the order is undefined.
For instance, when it comes to ranking functions, ORDER BY specifies the order in which ranks are assigned to rows.

Frame Specification

In the same OVER() clause, you can specify the upper and lower bounds of a window frame using one of the two subclauses, ROWS or RANGE. The basic syntax for both of these subclauses is essentially the same:

ROWS BETWEEN lower_bound AND upper_bound

RANGE BETWEEN lower_bound AND upper_bound

And in some cases, they might even return the same result. However, there’s an important difference.

In the ROWS subclause, the frame is defined by beginning and ending row positions. Offsets are differences in row numbers from the current row number.

As opposed to that, in the RANGE subclause, the frame is defined by a value range. Offsets are differences in row values from the current row value.

Types of SQL Window Functions

Window functions in SQL Server are divided into three main types: aggregate, ranking, and value functions. Let’s have a brief overview of each.

Aggregate Window Functions

• AVG(): returns the average of the values in a group, ignoring null values.
• MAX(): returns the maximum value in the expression.
• MIN(): returns the minimum value in the expression.
• SUM(): returns the sum of all the values, or only the DISTINCT values, in the expression.
• COUNT(): returns the number of items found in a group.
• STDEV(): returns the statistical standard deviation of all values in the specified expression.
• STDEVP(): returns the statistical standard deviation for the population for all values in the specified expression.
• VAR(): returns the statistical variance of all values in the specified expression; it may be followed by the OVER clause.
• VARP(): returns the statistical variance for the population for all values in the specified expression.

Sample query:

SELECT name, salary,
  SUM(salary) OVER (PARTITION BY dept) AS dept_total,
  AVG(salary) OVER (PARTITION BY dept) AS dept_avg
FROM employees;

Ranking Window Functions

Used to assign rank or position within partitions.

• ROW_NUMBER(): assigns a unique sequential integer to rows within a partition of a result set.
• RANK(): assigns a unique rank to each row within a partition with gaps in the ranking sequence when there are ties.
• DENSE_RANK(): assigns a unique rank to each row within a partition without gaps in the ranking sequence when there are ties.
• PERCENT_RANK(): calculates the relative rank of a row within a group of rows.
• NTILE(): distributes rows in an ordered partition into a specified number of approximately equal groups.

Sample query:

SELECT name, salary,
  RANK() OVER (PARTITION BY dept ORDER BY salary DESC) AS dept_rank
FROM employees;

Offset(Value) Window Functions

Used to access data from other rows.

• LAG(): retrieves values from rows that precede the current row in the result set.
• LEAD(): retrieves values from rows that follow the current row in the result set.
• FIRST_VALUE(): returns the first value in an ordered set of values within a partition.
• LAST_VALUE(): returns the last value in an ordered set of values within a partition.
• NTH_VALUE(): returns the value of the nth row in the ordered set of values.
• CUME_DIST(): returns the cumulative distribution of a value in a group of values.

Sample Query:

SELECT date, revenue,
  LAG(revenue, 1) OVER (ORDER BY date) AS prev_month,
  revenue - LAG(revenue, 1) OVER (ORDER BY date) AS change
FROM monthly_sales;

Summary

SQL window functions provide a powerful analytical layer within standard SQL, enabling complex calculations across related rows while preserving row-level granularity. Unlike GROUP BY, they do not collapse result sets, which makes them ideal for scenarios requiring both detail and aggregate insight in the same query.

The OVER() clause is central, with PARTITION BY defining logical groups, ORDER BY controlling calculation sequence, and optional frame specifications (ROWS or RANGE) refining scope.

Key functional categories include aggregate window functions for running totals and moving averages, ranking functions such as ROW_NUMBER() and RANK() for ordered comparisons and offset functions like LAG() and LEAD() for time-series or sequential analysis.

When used correctly, window functions significantly reduce query complexity, eliminate the need for self-joins in many analytical patterns and improve expressiveness in reporting and business intelligence workloads.

In the previous chapters, we learned how to have proper customer conversations — avoiding compliments, digging into specifics, and not pitching too early. But here’s a question that kept bugging me: How do I know if a meeting actually went well?

Chapter 5 answers exactly that. And the answer is brutally simple: a meeting went well only if it ends with a commitment.

Outline

In this post, I’ll break down Chapter 5 into the following sections:

1. There’s No Such Thing as a Meeting That “Went Well” — Why every meeting either succeeds or fails, and how compliments trick you into thinking you’re making progress.
2. Commitment and Advancement: Two Sides of the Same Coin — The two key concepts of the chapter and why they always come together.
3. The Currencies of Commitment — The three types of commitment (Time, Reputation, Money) and how they escalate in seriousness.
4. The Spectrum: From Zombie Lead to Committed Customer — How to read the signals and know exactly where you stand with a potential customer.
5. Why We Don’t Ask for Commitments (And Why We Should) — The two traps that prevent us from getting real signals: fishing for compliments and not asking for next steps.
6. The “Crazy” First Customers: Your Early Evangelists — Why your first customers won’t be “normal” buyers, and why that’s a feature, not a bug.
7. How to Push for Commitment Without Being a Used Car Salesman — A practical framework for asking for commitments without feeling pushy.
8. Don’t Ask for Commitment Too Early — Why timing matters and how to match your ask to the stage of the relationship.

There’s No Such Thing as a Meeting That “Went Well”

This was a mindset shift for me. I used to walk out of meetings thinking “That went great! They loved the idea!” — and then… nothing happened. No follow-up, no next steps, just silence.

Fitzpatrick puts it bluntly:

Every meeting either succeeds or fails.

A meeting fails when you leave with:

• A compliment: “That’s a really cool idea!”
• A stalling tactic: “Let’s circle back after the holidays.”

A meeting succeeds when you leave with:

• A commitment to the next step
• Something concrete that advances the relationship forward

The tricky part? The subtle stalls don’t feel like rejection. “We should definitely talk again soon” sounds positive, but it’s just a polished version of “Don’t call me, I’ll call you.”

Rule of Thumb: If you leave a meeting feeling good but without a concrete next step, you probably got played by a compliment, not a commitment.

Commitment and Advancement: Two Sides of the Same Coin

Fitzpatrick introduces two key concepts:

Commitment — When someone gives you something they value. This proves they’re serious and not just being polite.

Advancement — When the relationship moves to the next concrete step in your sales or learning process.

These two almost always come together. To advance to the next step, someone has to commit something. And if someone commits something, the process naturally advances.

For example: You want to demo your product to a company’s decision-maker. To get that meeting (advancement), your current contact needs to introduce you to their boss (reputation commitment). One doesn’t happen without the other.

Rule of Thumb: Commitment and advancement are functionally the same thing. If you’re getting one, you’re usually getting both. If you’re getting neither, the meeting failed.

The Currencies of Commitment

Not all commitments are created equal. Fitzpatrick breaks them down into three “currencies” — and they escalate in seriousness:

1. Time Commitment

This is the lightest form. The person is investing their time to engage with you further.

Examples:

• Agreeing to a follow-up meeting with clear next steps
• Sitting down for a longer, deeper conversation
• Trying out your prototype or beta and giving feedback
• Coming to your office (or going out of their way) for a meeting

If someone won’t even give you another 30 minutes of their time, that’s a pretty clear signal.

2. Reputation Commitment

This is heavier. The person is putting their name and credibility on the line for you.

Examples:

• Introducing you to their boss or a decision-maker
• Introducing you to a peer or potential customer
• Giving you a public testimonial or case study
• Posting about you on social media or their company Slack

When someone introduces you to their boss, they’re essentially saying “I believe in this enough to risk looking stupid if it doesn’t work out.” That’s real skin in the game.

3. Financial Commitment

The ultimate signal. Money talks, everything else walks.

Examples:

• A letter of intent (LOI) or pre-order
• A deposit or partial payment
• Pre-paying for the product before it’s built

If someone says “I’d definitely pay for that” — that means nothing. If someone says “Here’s $500, let me know when it’s ready” — that means everything.

Rule of Thumb: The more someone gives you (time → reputation → money), the more seriously you can take their signal. Compliments cost nothing. Commitments cost something. That’s the whole difference.

The Spectrum: From Zombie Lead to Committed Customer

Fitzpatrick describes a spectrum of signals you might get from potential customers, and it’s incredibly useful for figuring out where you actually stand:

Cold signals (the meeting failed):

• “That’s cool, I like it” → compliment, worthless
• “Looks interesting, keep me in the loop” → polite brush-off
• “Let’s grab coffee sometime” → stalling, no specifics
• No follow-up after the meeting → they forgot you exist

Warm signals (getting somewhere):

• “Can you show this to my team next Tuesday?” → time + reputation commitment
• “Send me the beta link, I’ll try it this week” → time commitment with a deadline
• “Let me introduce you to our Head of Product” → reputation commitment

Hot signals (you’re onto something):

• “How much would this cost? Can we do a pilot?” → moving toward financial commitment
• “We’d like to pre-order 50 licenses” → money on the table
• “Here’s a deposit, build it” → they’re all in

Rule of Thumb: If you can’t tell where someone falls on this spectrum, you didn’t push hard enough for a commitment at the end of the meeting.

Why We Don’t Ask for Commitments (And Why We Should)

So if commitments are so important, why don’t we ask for them? Fitzpatrick identifies two main traps:

Trap 1: You’re Fishing for Compliments

Instead of asking “Would you be willing to pay for this?” or “Can I show this to your boss?”, we ask soft questions like:

• “What do you think of the idea?”
• “Would you use something like this?”

These questions are begging for a compliment, not a commitment. And guess what? People are happy to give you a compliment because it costs them nothing and gets you out of the room.

Trap 2: You’re Not Asking for Next Steps

The meeting is going well. You’re vibing. You’re having a great conversation. And then… you just let it end. No ask. No push. You walk away with warm feelings and zero concrete progress.

This is fear dressed up as politeness. We don’t want to be “pushy” so we don’t ask. But here’s the thing — if your product is genuinely solving their problem, asking for a next step isn’t pushy. It’s helpful.

Rule of Thumb: Always know what commitment you want before the meeting starts. Then ask for it before the meeting ends. If you don’t ask, you won’t get it. Period.

The “Crazy” First Customers: Your Early Evangelists

Fitzpatrick makes an important point about who your first customers will be. They won’t be normal, rational, cautious buyers. Your first customers will be a little bit “crazy” — and that’s a good thing.

Your early evangelists typically:

• Have the problem right now, not “someday”
• Know they have the problem — they’re not in denial
• Have already tried to solve it (maybe with spreadsheets, duct tape, or a competitor)
• Have the budget or authority to actually pay for a solution
• Are desperate enough to try an unfinished, unpolished product from an unknown startup

Think about it: a normal person wouldn’t use a half-built product from two people in a garage. But someone who’s in pain RIGHT NOW and has been looking for a solution? They’ll tolerate bugs, missing features, and a terrible UI — because you’re solving their burning problem.

These people are gold. They give you real feedback, real money, and real validation.

Rule of Thumb: If you can’t find anyone who’s desperate enough to use your product in its current state, you either haven’t found your real customer segment, or you’re not solving a painful enough problem.

How to Push for Commitment Without Being a Used Car Salesman

A common fear: “But I don’t want to be pushy!”

Fitzpatrick’s answer: you’re not being pushy if you’re genuinely trying to help. Here’s his framework:

1. Know your ask before the meeting. What’s the ideal next step? An intro to the boss? A pilot program? A pre-order? Know this going in.

2. Ask at the end of the meeting. Don’t let the meeting fizzle out. Before wrapping up, clearly state what you’d like to happen next.

3. Accept the answer gracefully. If they say no, that’s actually great information. A clear “no” is infinitely more useful than a wishy-washy “maybe.” At least now you know where you stand.

4. Interpret the response honestly. If they dodge, stall, or give you a compliment instead of a commitment — recognize it for what it is. Don’t lie to yourself.

Examples of good asks:

• “Would you be willing to do a trial run with your team next month?”
• “Could you introduce me to [decision-maker] so I can understand their perspective?”
• “If we build this by March, would you commit to being a pilot customer?”
• “Can I get a letter of intent so we can prioritize building this feature for you?”

Rule of Thumb: If you’re afraid to ask for a commitment because you think the person will say no — that’s exactly why you need to ask. A “no” now saves you months of chasing a dead lead.

Don’t Ask for Commitment Too Early

Here’s the balance: pushing for commitment is essential, but timing matters.

If you push for money or a huge commitment during what’s supposed to be an early learning conversation, you’ll scare people away. The first few conversations should be about learning — understanding their problem, their workflow, their pain.

Once you’ve validated the problem and have something to show (even a rough prototype), THEN you start pushing for commitments.

The progression looks like this:

1. Early conversations: Learn about the problem. No pitch, no ask. Just listen.
2. Problem validated: Start showing your solution concept. Ask for time commitments (follow-up meetings, beta testing).
3. Solution takes shape: Push for reputation commitments (introductions, referrals).
4. Product is tangible: Push for financial commitments (pre-orders, deposits, LOIs).

Skipping steps or pushing too hard too early is just as bad as never pushing at all.

Rule of Thumb: Match your ask to the stage of the relationship. Early = learn. Middle = time and reputation. Late = money.

Key Takeaways from Chapter 5

Let me sum up the core lessons:

1. Meetings don’t “go well.” They either produce a commitment or they fail. Stop fooling yourself with compliments.

2. Commitments come in three currencies: Time, Reputation, and Money — in escalating order of seriousness.

3. Always push for a next step. Know your ask before the meeting and make it before the meeting ends.

4. Compliments ≠ Commitments. “That’s a great idea” is worthless. “Here’s my credit card” is priceless.

5. Your first customers will be “crazy.” They have the problem now, they know it, and they’re desperate enough to use your unfinished product.

6. A “no” is better than a “maybe.” Rejection gives you clarity. Wishy-washiness wastes your time.

7. Match your ask to the stage. Don’t ask for money when you should be asking questions. Don’t ask for opinions when you should be asking for money.

This is part of my series where I break down each chapter of The Mom Test by Rob Fitzpatrick. If you’re building a product and talking to customers, this book is essential reading.

Previously: Chapter 4 – Why You Should Keep Customer Conversations Casual
Next up: Chapter 6 – Finding Conversations

Introduction

“I want to deploy to AWS, but writing CloudFormation YAML is a pain…” “Azure has too many configuration options…” Sound familiar?

I had the same frustrations until I tried WinClaw‘s cloud auto-deploy skills. Just by having a conversation with AI, I got my app deployed to AWS, Azure, and Alibaba Cloud — fully automated.

What is WinClaw Cloud Deploy?

WinClaw is a free, open-source AI development tool with three cloud deployment skills:

• aws-cloud-deploy: Auto-generates CloudFormation templates
• azure-cloud-deploy: Auto-generates ARM templates
• aliyun-cloud-deploy: Auto-generates ROS templates

All three providers share the same conversational workflow — great for multi-cloud environments.

The Interactive Deploy Experience

Phase 1: Requirements Hearing

The AI asks you natural questions:

• Monthly budget: “How much can you spend per month?” → e.g., $50/mo
• Expected traffic: “Daily visitors?” → e.g., 1,000 PV/day
• Security needs: “Handling personal data?” → Yes/No
• Availability: “Acceptable downtime?” → e.g., < 30 min/month

Phase 2: Architecture Proposal

Based on your answers, the AI proposes the optimal architecture from 6 patterns:

Security Tiers

Security is also auto-selected from 3 tiers:

• Basic (Free): Security Groups + IAM Roles
• Standard ($10-30/mo): WAF + VPC Flow Logs + Encryption
• Enterprise ($200-3,500/mo): Shield Advanced + GuardDuty + Config Rules + Audit Logs

Phase 3: Automated Deployment

After confirming the architecture, everything runs automatically:

1. Phase 3A — IaC template generation (CloudFormation/ARM/ROS)
2. Phase 3B — Code deployment
3. Phase 3C — Health checks + auto-fix on errors
4. Phase 3D — Report generation (access URL, cost estimate)

Same Experience on Azure & Alibaba Cloud

Azure generates ARM templates and selects from App Service / VM / AKS / Functions.

Alibaba Cloud generates ROS templates and selects from ECS / FC / ACK. Supports China’s MLPS 2.0 compliance.

Getting Started

WinClaw is completely free and open-source:

• GitHub Repository
• SourceForge Downloads

Use GLM-5 (free) as the LLM backend:

set ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic
set ANTHROPIC_AUTH_TOKEN=your-api-key
set ANTHROPIC_MODEL=glm-5

Conclusion

WinClaw’s cloud deploy skills dramatically lower the barrier to infrastructure setup. Just answer questions about budget and traffic, get an optimal architecture proposal, and watch as everything deploys automatically. Once you try it, there’s no going back. Give it a shot!

When you’re new to Go, error handling is definitely a paradigm shift that you need to come to terms with. Unlike in other popular languages, in Go, errors are values, not exceptions. What this means for developers is that you can’t just hide from them – you have to handle errors explicitly and at the point of the call. That equals a lot of if err != nil { return err }. But more importantly for us now, since errors are values, they can also be passed around, inspected, and composed like any other variable. This opens the door to many security issues if you’re not careful.

This guide walks you through best practices for secure error handling in Go. We’ll look at the reasons why it’s so important, how it affects security, and how to securely create, wrap, propagate, contain, and log errors. We’ll also provide a checklist on how to handle specific Go errors securely.

Bear in mind that this is an article on the security aspect of error handling in Go, so it focuses on best practices and user-facing messages. If you’re looking for a primer on general error handling mechanics in Go, check out our exhaustive How to Handle Errors in Go tutorial.

Why does secure error handling matter in Go?

To be precise, secure error handling matters in all programming languages, but with Go, errors carry particular weight.

For one thing, Go services often run in highly security-sensitive and distributed environments. A lot of Go is used for writing APIs, cloud services, and microservices – types of infrastructure with significant potential for security breaches that carry severe consequences and, due to their distributed nature, can have a rippling effect.

On the other hand, as already hinted in the introduction, the error-handling paradigm in Go makes developers somewhat vulnerable to disclosing sensitive information, such as paths, SQL queries, credentials, identifiers, or stack traces. Meanwhile, if you look at typical guides on error handling in Go, they seem to overlook the critical security aspect of containing and sanitizing your errors. Instead, they will teach you how to be specific and explicit, so that errors can be logged properly and debugged efficiently. But what happens if you expose these verbose errors to clients at runtime?

That’s how Go errors leak internal information

Errors in Go are values like any other, just with the error type. You decide what to do with that value, and so your program’s security depends entirely on how you create and expose errors.

If you fail to contain and sanitize them, you expose your app to a torrent of security issues, ranging from the disclosure of personally identifiable data to enumeration attacks. Take the recent example of CVE-2025-7445, a vulnerability in Kubernetes that allowed actors with access to the secrets-store-sync-controller logs to observe service account tokens in specific error-marshalling scenarios.

This shows that error handling in Go requires caution and sound design choices. But when done right, it pays off with improved API safety, clean logs, and better resistance to hacks.

Secure patterns for error creation and wrapping in Go

Now that we’ve covered why secure error handling is so important, let’s see how to design errors in Go without exposing sensitive information.

To have secure code, you need to treat errors as data objects that require sanitization. But to have practical code, you need enough information to debug it when problems arise. By adhering to the following three principles, you can achieve both.

Split brain (but a good one)

The most effective way to prevent accidental information leaks is to formalize the distinction between what the system sees and what the user sees. Relying on ad-hoc string manipulation at the level of HTTP handlers? I think you’ll agree that approach is prone to human error. So, instead, you need to define a custom error type that enforces this separation at the compile level.

It can look something like this: You create a struct that encapsulates both the Internal (unsafe) and the Public (safe) message.

package secure

// SafeError implements the error interface but keeps secrets internal.

type SafeError struct {

    // Machine-readable code for clients (e.g., "RESOURCE_NOT_FOUND")

    Code string 

    // Human-readable message safe for public consumption

    UserMsg string 

    // The raw, upstream error (DO NOT expose this via API)

    Internal error 

    // Context map for structured logging (sanitized)

    Metadata map[string]string

}

// Error satisfies the stdlib interface. 

// CRITICAL: This returns the SAFE message, not the internal one.

// This prevents accidental leaks if the error is printed directly to an HTTP response.

func (e *SafeError) Error() string {

    return e.UserMsg

}

// LogString returns the detailed string for your SRE team.

func (e *SafeError) LogString() string {

    return fmt.Sprintf("Code: %s | Msg: %s | Cause: %v | Meta: %v", 

        e.Code, e.UserMsg, e.Internal, e.Metadata)

}

You can check out this Go error library by Cockroach Labs to see a real-life implementation of this principle and read an interesting article on how they approach logging and error redaction for additional inspiration.

Why is this more secure?

Let’s say a developer accidentally passes the above error to http.Error(w, err.Error(), 500). The user will only see the sanitized UserMsg, but the sensitive SQL syntax error or upstream timeout token will remain hidden inside the struct. They’re accessible through the LogString() method used by your logging middleware.

Contextual sanitization

Errors rarely happen in a vacuum, so you need context (variables, IDs, inputs) to debug. But blindly adding context is how sensitive data leaks into the logs.

This is what you don’t do:

// DANGEROUS: Logging raw input structures
if err != nil {
    return fmt.Errorf("login failed for request %v: %w", authRequest, err)
}
// If authRequest contains a 'Password' field, you just wrote it to disk.

And this is what you do instead – use a builder pattern or helper function that explicitly allows lists of safe metadata fields:

func NewAuthFailed(public string, internal error, safeMeta map[string]string) *SafeError {
    return &SafeError{
        Code:     "AUTH_FAILED",
        UserMsg:  public,
        Internal: internal,
        Metadata: safeMeta,
    }
}

// Usage:
if err != nil {
    return NewAuthFailed(
        "Invalid credentials.",
        err,
        map[string]string{
            "username":  req.Username,
            "ip_addr":   req.RemoteIP,
            "attempt_id": GenerateRequestID(),
        },
    )
}

Why is this more secure?

By using an explicit builder pattern or helper function, you force yourself to inspect everything and choose what gets logged rather than defaulting to “everything”.

Opaque wrapping

Standard wrapping using fmt.Errorf("... %w", err) creates a chain. While excellent for debugging, this allows errors.Is and errors.As (from version 1.26 errors.AsType as well) to traverse down to the root cause. In high-security contexts, you may want to prevent the caller from introspecting the underlying library entirely.

For that, you wrap the error in a way that captures the stack trace and context, but breaks the dependency chain for the caller.

func GetUserProfile(id string) (*Profile, error) {
    // Imagine this returns a specific database error containing table names
    // e.g., "pq: relation 'users_v2' does not exist"
    user, err := db.QueryUser(id) 
    if err != nil {
        // BAD: returns raw DB error.
        // return nil, err 

        // BAD: wraps, but exposes the underlying type via Unwrap().
        // return nil, fmt.Errorf("db error: %w", err) 

        // GOOD: Opaque wrapping.
        // We log the raw error here or wrap it in a type that doesn't 
        // expose the cause via Unwrap() to the external world.
        return nil, &SafeError{
            Code:      "FETCH_ERROR",
            UserMsg:   "Unable to retrieve user profile.",
            Internal:  err, // Stored for logs, hidden from Unwrap logic if needed
        }
    }
    return user, nil
}

Why is this more secure?

By explicitly controlling how your custom error type implements (or doesn’t implement) Unwrap(), you act as a firewall. You ensure that a vulnerability in a third-party XML parser or SQL driver cannot be introspected or triggered by a malicious user manipulating inputs to check for specific error types.

Safe error propagation

Go is one of the most popular choices for distributed systems, like microservices, cloud functions, and APIs. In an environment like that, an error is not just a local event – it usually bubbles up somewhere upstream.

One of the most dangerous “security” habits in Go is letting errors bubble up unfiltered. Like when an error originating in the database layer is returned up the stack, function by function, until it’s serialized directly to the user’s screen. Then, instead of a simple File not found, unauthorized actors get access to your internal architecture – file paths, library versions, IP addresses, and schema details.

That’s why when working with distributed architectures, proper error containment is a top priority for security. Depending on which trust boundary the data crosses, we can distinguish three distinct levels of containment and patterns to deal with it.

Crossing subsystem boundaries

Sanitize your data when it crosses subsystem boundaries, like when it moves from a data access layer (DAL) to a business logic layer (BLL). If your database fails, the BLL doesn’t need to know why it happened, only that it did. Wrap the raw error in a domain-specific one, for example:

• Raw: pq: duplicate key value violates unique constraint "users_email_key"
• Sanitized: domain.ErrDuplicateUser (wrapping the raw cause) 

Otherwise, you’re risking leaking implementation details, such as revealing that you’re using PostgreSQL rather than MongoDB.

Crossing API boundaries

Translate your error in service-to-service communication, like billing calling your auth service. Convert Go error types into standardized protocol errors (gRPC status codes or standard JSON error responses). The upstream service only needs to know how to react, not which line of code broke.

Not translating errors can result in cascading failures and risks exposing stack traces to other services that don’t need to know the ins and outs of your code.

// BillingService → AuthService call
resp, err := s.auth.ValidateToken(ctx, token)
if err != nil {
    var authErr *secure.SafeError
    if errors.As(err, &authErr) {
        // Translate domain error → protocol
        return nil, &secure.SafeError{
            Code:     "AUTH_UNAVAILABLE",
            UserMsg:  "Authentication service is temporarily unavailable.",
            Internal: err, // keep original cause for logs
            Metadata: map[string]string{"svc": "auth"},
        }
    }

    // Unknown error → generic translation
    return nil, &secure.SafeError{
        Code:     "INTERNAL",
        UserMsg:  "Internal service error.",
        Internal: err,
    }
}

Crossing public boundaries

Wrap your errors in generic messages when crossing public boundaries, like from your public API gateway to the end user. They should never see a generated error message, only a static, pre-defined string or code (like Service temporarily unavailable. Request ID: abc-123, not Connection timeout to redis-cluster-01 at 10.0.1.5:6379). Otherwise, you risk giving attackers hints for SQL injection, path traversal, or denial of service (DoS) attacks.

// Handler serves the HTTP request
func (s *Server) HandleCreateOrder(w http.ResponseWriter, r *http.Request) {
    // 1. Execute Logic
    // Errors bubble up, containing stack traces and SQL details
    err := s.orders.Create(r.Context(), reqBody)

    if err != nil {
        // 2. Log the "Truth"
        // We log the FULL internal error for the security/dev team
        s.logger.Error("failed to create order", "error", err, "stack", stack.Trace(err))

        // 3. Contain and Translate for the User
        // We never just write 'err.Error()' to the response writer.
        translateAndRespond(w, err)
        return
    }

    w.WriteHeader(http.StatusCreated)
}

func translateAndRespond(w http.ResponseWriter, err error) {
    var status int
    var publicMsg string

    // We inspect the error type or sentinel value to decide the "Public Face" of the error
    switch {
    case errors.Is(err, domain.ErrInvalidInput):
        status = http.StatusBadRequest
        publicMsg = "The provided order details are invalid."
    case errors.Is(err, domain.ErrConflict):
        status = http.StatusConflict
        publicMsg = "This order has already been processed."
    case errors.Is(err, context.DeadlineExceeded):
        status = http.StatusGatewayTimeout
        publicMsg = "The request timed out."
    default:
        // CATCH-ALL: The most important security catch.
        // If we don't recognize the error, we assume it's sensitive internal state.
        status = http.StatusInternalServerError
        publicMsg = "An internal error occurred. Please contact support."
    }

    http.Error(w, publicMsg, status)
}

Logging errors without leaking sensitive data

Even internal logs should be sanitized in anticipation of a possible leak. You should move from the mindset of “logging everything” to only “logging safe context that’s needed.” Here are some key rules when it comes to logging errors securely:

1. Use structured logging

Stop using fmt.Printf or string concatenation. Use a structured logger (like Go’s standard log/slog or libraries like zap and zerolog). Structured logging treats log parameters as typed data, not raw strings. This significantly reduces the risk of log injection attacks because the logger handles the escaping of special characters.

2. Sanitize before logging

Never log a struct directly unless you have verified it contains no personal data. Instead, use a pattern where you explicitly map only the fields required for debugging (see the Contextual sanitization section above).

3. Redact at middleware

For data that must be logged but contains sensitive parts (like a full HTTP request for debugging), implement a Redactor interface.

type Redactor interface {
    Redact() any
}

type LoginRequest struct {
    Username string
    Password string
}

func (r LoginRequest) Redact() any {
    return struct {
        Username string `json:"username"`
        Password string `json:"password"`
    }{
        Username: r.Username,
        Password: "***REDACTED***",
    }
}

// logger usage:
logger.Info("login attempt", "req", req.Redact())

func LogRequest(r *http.Request) {
    // Basic scrubbing of common sensitive headers
    safeHeaders := r.Header.Clone()
    safeHeaders.Del("Authorization")
    safeHeaders.Del("Cookie")
    
    slog.Info("incoming request",
        slog.String("path", r.URL.Path),
        slog.Any("headers", safeHeaders), // Safe to log now
    )
}

4. Check everything

Security relies on consistency, but we humans are notoriously inconsistent. Use your IDE to catch the insecure logging patterns before they compile. Some features that are helpful for secure error handling in GoLand are:

• Printf validation: GoLand detects if the arguments passed to a formatting function don’t match the verbs, reducing the risk of accidental data leaks through malformed strings.
• Taint analysis: Through data flow analysis, GoLand can track variables from untrusted sources (like HTTP bodies) and warn you if they are being used in dangerous sinks (like raw string concatenation in logs) without sanitization.

Time to check your codebase

If you feel like any of these golden rules are news to you, maybe it’s time to do a security audit of your codebase. To make it easier for you, here’s a checklist of some questions that you may ask yourself about how your application handles errors with best practices for different scenarios.

Security audit checklist

Frequently asked questions

Can I return err.Error() directly to API clients?

No. err.Error() is designed for debugging by developers. It can leak implementation and structure information to hackers.

What is the safest way to return errors in Go APIs?

You should return structured, sanitized protocol errors that provide just enough information for the client to react, while keeping technical details hidden.

How do I prevent Go errors from leaking sensitive information?

First and foremost, decouple system information from user-facing messaging and never provide raw errors to end users. Know when data crosses boundaries and only provide as much context as needed to resolve the issue. If sensitive data must be logged, redact it.

How can Go services safely log errors without exposing secrets?

Shift your mindset from “log everything” to “sanitize everything”. You should make sure that your logs are rich enough to debug issues, but sterile enough that the system and users won’t be compromised if leaked.

What is the difference between propagating and translating errors in Go?

When you propagate an error, you run it up the call stack (usually wrapped in context with %w). This preserves the details and stack trace for easier debugging.

Translating an error means catching and replacing it with a different, domain-specific error (like swapping an sql.ErrNoRows for a UserNotFound) to hide implementation details from the caller.

A good rule of thumb for security is propagating errors internally between subsystems and translating them at the API boundary to prevent leaks.

When should a Go application fail fast for security reasons?

An app should fail fast for security reasons if it detects conditions that compromise trust, integrity, or confidentiality. Some scenarios where this might be applicable are: authentication failure, insecure input (like known SQL injection patterns), resource exhaustion (early sign of DoS attack) – fail fast, don’t panic; integrity check failure or tampered configuration – panic.

How do you design secure user-facing error messages in Go?

Use a custom error type that holds both private error details and safe public messages. Only return public messages to the client. Make sure they are generic, opaque, and standardized. Never provide specific technical details and only provide safe context to the extent that it’s necessary for tracing.

How should upstream service or database errors be handled securely in Go?

Upstream service and database errors must be handled securely by containing and translating them at the service boundary to prevent information leakage.

Containment means that raw errors should not be propagated across service or API trust boundaries. Translation means that raw errors should be mapped to generic, domain-specific errors defined in the service.

What are common security mistakes in Go error handling?

Most security mistakes when it comes to error handling in Go boil down to over-exposure of internal details. Common mistakes include:

• Propagation of raw errors across trust boundaries.
• Accidentally logging secrets.
• Exposing raw stack traces or verbose internal error messages to end users.
• Relying on a generic handler that returns err.Error(), instead of custom error types.

How can GoLand help detect insecure error patterns?

GoLand can help you detect insecure error patterns primarily through static code analysis (inspections) and data flow analysis. Here are some key detection features you might be interested in:

• Detection of unhandled errors: GoLand automatically flags functions that return an error but have been called without checking it.
  Proceeding with an operation when a check has failed (or didn’t occur at all) might result in an authentication bypass – the program serving sensitive data to an unauthenticated user.

• Detection of nil pointer deference and data flow analysis: GoLand tracks how nil values move across functions and files to warn you about a potential nil variable. It also reports instances where variables might have nil or an unexpected value because an associated error was not checked for being non-nil. 
  Unchecked nil variables can cause a panic that results in an inconsistent state or be exploited in DoS attacks.

• Resource leak inspection: Resource leak analysis in GoLand analyzes your code locally to ensure that any object implementing io.Closer is properly closed.
  Resource leaks pose a security threat because, when exploited, they are a gateway for DoS attacks.

• Package Checker: This plugin analyzes third-party dependencies for known vulnerabilities and updates them to the latest released version.
  This protects you from known exploits and helps you remain compliant with regulatory requirements.

• Type assertion on errors: GoLand reports type assertion or type switch on errors, for example, err.(*MyErr) or switch err.(type), and suggests using errors.As instead.

• errors.AsType: After the introduction of errors.AsType in Go 1.26, GoLand reports usages of errors.As that can be replaced with this generic function that unwraps errors in a type-safe way and returns a typed result directly.

The GoLand team

Lately I’ve decided to keep mental notes of everyday concepts I use in my work. Most times I have a good overview of what a concept does but I never really understood what goes on under the hood. I mean, it works innit. But I’m taking a step further with some of those concepts, and today’s subject is all about Client Side Rendering(CSR) and Server Side Rendering(SSR).

Before SSR was a thing

We all know how wonderful Single Page Applications(SPAs) are, but to really appreciate SSR, we need to go back a little.

So basically, the traditional way of displaying content on the internet is this little relationship that happens between the client, which is your browser and the server, whatever web hosting platform your content lives on.

The browser asks the server for a page, the server returns an index.html with a <script> tag at the bottom pointing to a main.js file, the browser then makes another request to fetch that main.js and executes it.

<!-- index.html -->
<div id="root"></div>
<script src="/main.js"></script>

If you look closely at that main.js, you will find something like this

ReactDOM.createRoot(document.getElementById("root")).render(<App />);

This is where React takes over. It runs your components, converts JSX(JavaScript XML) into JavaScript objects, what we call the Virtual DOM, and then converts those JavaScript objects into actual DOM nodes the browser can display.

So your JSX that looks like this:

jsx
`<h1 className="title">Hello World</h1>`

gets converted into a Javascript object like this:

js
{
type: "h1",
props:{
className: "title",
children:"Hello World"
}
}

That’s your virtual DOM right there, just a plain JavaScript object describing what the UI should look like. React then takes that object and creates an actual DOM node from it:

js
HTMLHeadingElement: node.textContent = "Hello World"`

And appends it to the #root div. Boom, the browser displays it. That’s basically CSR.

State updates and reconciliation

Now a huge part of any UI is state: counter, cart items, form inputs, all of that. When state updates, React doesn’t re-download main.js and redo everything from scratch; that would be crazy expensive.

What React actually does is look at the component where the update happened, build a new virtual DOM, compare it to the previous one, find what changed, and update only those nodes in the actual DOM. The process is called reconciliation and it’s honestly wild how all of this happens without a full page refresh.
And that whole process I just described, the browser downloading JS, React building the virtual DOM, reconciliation and all — that’s Client Side Rendering.

Then SSR came along

SSR is so beautiful because it offloads a huge chunk of this work from the browser and just does it on the server instead.

Now “the server” can sound confusing, but here is the thing, JavaScript can run in two primary environments: the browser and Node.js. So in SSR, it’s Node.js doing all the heavy lifting.

Here’s what happens when you request a page:
The Node.js server runs React, calls your component function, parses JSX, builds the virtual DOM and converts everything into readable HTML, then sends that fully structured HTML straight to the browser. The browser receives real HTML and can display it immediately, no waiting for JS to build everything from scratch.

html
<div id="root">
<h1>Hello</h1>
<p>This came from the server</p>
</div>

But that’s not the end of it. In the background the JavaScript bundle also loads, and once it does, hydration happens.

Okay but what even is hydration?

Hydration is basically the process of attaching interactivity, specifically event listeners, to the HTML the server already sent. Think of it like the server sending you a fully built house, and hydration is the electrician coming in afterwards to wire everything up.

In CSR, React uses createRoot which builds everything from scratch. In SSR, React uses hydrateRoot which assumes the DOM already exists, all it does is recreate the virtual DOM and attach event handlers to the right elements.

js// CSR - builds from scratch
ReactDOM.createRoot(document.getElementById("root")).render(<App />);

// SSR - assumes HTML exists, just wires it up
ReactDOM.hydrateRoot(document.getElementById("root"), <App />)

So How does this affect how I write Next.js Code

Next.js does SSR by default. Every component runs on the server first, even ones marked with "use client" directive. The difference is that "use client" tells the compiler that this component needs to be hydrated on the client so it can handle interactivity.

So the rule is simple, anywhere you need state, effects, browser APIs like document.querySelector or even event listeners, add "use client" at the top of the file. If you don’t, your code will be trying to access browser APIs that don’t exist on the server and you will be staring at errors wondering what went wrong.

"use client";

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

So what does this mean for how I build components

Honestly this is the part that changed how I think at work. Once you understand CSR and SSR, you stop throwing use client everywhere and start asking, does this component actually need to run on the client?

The mistake I made early on was throwing use client at the top of every component. It just felt like the thing to do coming from plain React. But once I understood what was actually happening under the hood, I realized I was basically opting out of SSR everywhere and losing all the performance benefits for free.

A good rule of thumb, if a component just displays data with no clicks, no state, no user interaction, leave it as a server component. Only reach for use client when the component actually needs to respond to the user. That way the browser only handles what it truly needs to.

Wrapping up

It’s honestly crazy how much is happening under the hood every time a page loads. Understanding this whole flow — CSR, virtual DOM, reconciliation, SSR, hydration — really changed how I think about building components and where I put my logic.

Let me know what part clicked for you or if there’s anything you’d push back on — I’d really love to hear it.
See you next time. Byeeee

This article was brought to you by Rajkumar Venkatasamy, draft.dev.

Migrating from Jenkins can feel risky. Your pipelines work, your jobs run, and your scripts hold everything together. Jenkins isn’t broken, but over time, plugin sprawl, configuration drift, and upgrade headaches can quietly drain engineering time.

But what if there’s another option?

TeamCity’s user-friendly interface, built-in features, and seamless integrations can streamline your DevOps while reducing your reliance on plugins. 

You don’t need to migrate everything at once. Start small. Move a single standalone project (a basic build or unit test job) and run it in parallel with Jenkins. This lets you evaluate TeamCity’s built-in features, cleaner configuration, and reduced maintenance overhead without disrupting your existing workflows.

In this guide, we’ll walk you through how to migrate one project step by step, so you can test TeamCity before committing to a full transition.

How to move a single Jenkins project to TeamCity without breaking things

In this article, we’ll walk you through the migration process step by step so you can replicate it confidently. The key is methodical preparation, careful implementation, and thorough validation.

To really benefit from this guide, it’s best if you understand basic DevOps concepts and have hands-on experience with DevOps tools like Jenkins/TeamCity.

Preparation

Before touching TeamCity, take stock of your Jenkins job. This inventory phase is important because it uncovers dependencies that could trip you up later.

Start by selecting a simple, standalone job. An ideal candidate is a basic build-only task or a set of unit tests that aren’t constrained by complex pipelines or shared resources.

For example, log in to your Jenkins instance and navigate to the job’s Configuration page. Document everything: The source code repository (e.g. Git URL and branch), triggers (like on-commit webhooks or schedules), environment variables, and any build steps (such as shell commands or Maven/Gradle goals for a Java project):

Note the plugins in use. Jenkins often relies on plugins for basic integrations (like the Git plugin), whereas TeamCity handles much of this functionality natively:

It’s also helpful to note performance baselines, like the build-run wait times and duration. This gives you metrics to compare post-migration:

If your Jenkins job uses credentials, list them securely:

Spending 30 to 60 minutes tracking down all this info can save hours of debugging.

Implementation

When you’ve completed your preparation phase, it’s time to bring TeamCity online.

Start by setting up your TeamCity server by choosing one of the following options: TeamCity Cloud or on-prem. TeamCity Cloud is great for quick, managed hosting. It’s also ideal for testing, as it’s hassle-free and requires no provisioning.

However, the trial is only fourteen days, so make sure that you’ve set aside time for testing. You can also choose to install our on-premises version for full control.

Creating a new project and connecting your repository

Once the TeamCity setup is complete, log in to the UI and create a new project. Enter your GitHub repo URL (e.g. https://github.com/yourorg/yourrepo.git) and configure authentication. Use an access token or SSH key for security, depending on your repo setup. TeamCity supports major providers out of the box. This ensures that builds automatically pull the latest code.

TeamCity handles branching and change detection natively using webhooks and path filters, so you get faster, more reliable triggers without having to install or maintain any plugins.

Adding and customizing build steps

Once your project is created, TeamCity looks at your pom.xml or build.gradle and suggests the next Maven or Gradle build steps, which you can customize as needed.

You can then replicate the required build steps from your Jenkins job in the TeamCity project’s build configuration.

TeamCity provides numerous built-in runners with no plugins required. For a Maven build, select the Maven runner and input goals like “clean package”; for Gradle, choose the Gradle runner and enter your tasks the same way. You can find detailed instructions for tweaking runners and adding extra options in this guide.

If your Jenkins step was a generic shell command, opt for TeamCity’s Command Line runner. Unlike in Jenkins, where you might default to “Execute shell” for everything, which often results in less-structured, harder-to-maintain jobs, TeamCity encourages more organized, maintainable build steps.

If you’re more code-oriented and prefer scripting over UI clicks, TeamCity offers configuration as code via the Kotlin DSL. This is helpful for version-controlled setups, similar to Jenkins’s Groovy pipelines, but with type safety and IDE support. It lets you commit your configs to Git, enabling reviews and rollbacks, which is perfect for teams who treat infrastructure as code.

And here’s the best part: You don’t have to choose between UI and code! You can start in the UI, play around with your build configuration, get everything working, and when you’re ready, click View as code. TeamCity autogenerates clean, ready-to-commit Kotlin code based on your UI setup. 

This means you can learn visually, validate that everything works, then export to code with zero friction and no retyping.

If you’re interested in learning more, check out this developer’s guide on shifting from Groovy DSL to Kotlin DSL.

Setting up build triggers for automation

Once you’ve customized build steps, configure build triggers to automate runs. In the triggers section of TeamCity’s Build configuration, add a VCS trigger for on-commit builds. This enables the tool to watch your repo for changes and kick off builds. For scheduled jobs, use Schedule trigger to specify cron-like expressions.

TeamCity’s build triggers go far beyond “run on commit” or “run on a schedule”. They include Finish Build Trigger, VCS Trigger, and Retry Build Trigger:

Advanced triggering: Chaining builds without plugins

TeamCity only lets one build configuration automatically start another when a specific condition is met. 

In Jenkins, achieving the same level of orchestration often means installing and configuring extra plugins (like the Parameterized Trigger plugin or Pipeline: Multibranch), each of which adds maintenance overhead and potential version-compatibility headaches. 

With TeamCity, these capabilities are available out of the box, so you can chain builds, promote artifacts, or gate deployments without leaving the core product.

Real-time GitHub status updates

TeamCity also instantly posts detailed commit statuses back to GitHub as Passed, Failed, or In Progress, with direct links to the exact build log. 

This real-time feedback loop, powered by TeamCity’s native GitHub integration, doesn’t require additional plugins or webhooks. Developers see the outcome seconds after pushing, not minutes later after a polling interval or a misconfigured webhook or plugin.

Managing parameters and environment variables

Add build parameters and environment variables. TeamCity’s model backing the parameters and environment variables configuration is flexible and secure. You can define both parameters and environment variables (be it sensitive or nonsensitive variables) in the Parameters section by choosing text for simple strings, password for secrets (stored encrypted on the server, never exposed in logs), or select for dropdown options.

For instance, if your Jenkins job uses a nonsensitive env var like APP_NAME, create a new environment-variable input parameter with the value type set as text, and key in the value as Your_APP_NAME.

If your Jenkins job uses a sensitive env variable like DB_PASSWORD, create a password parameter in TeamCity. You can refer to these env variables as %DB_PASSWORD% in steps or as ${DB_PASSWORD} in custom scripts within TeamCity.

Secure secrets handling

Unlike Jenkins, which requires separate plugins for secrets management and vault integration, TeamCity has native support for external vaults, like HashiCorp Vault, keeping sensitive data centralized and audit-friendly.

This step builds resilience as parameters allow easy overrides for different environments without rewriting or setting up the build configuration for each environment.

Validation and cutover

Once you’ve built the project in TeamCity, you need to verify that it works. Start by manually triggering a build in TeamCity. Watch the logs in real time; TeamCity’s interface highlights errors and provides timestamps for you to easily observe and troubleshoot when needed. Compare the artifacts and results against your Jenkins baseline.

If issues occur during the build process execution, common causes could be path mismatches (TeamCity’s checkout directory might differ, and in such a case, make adjustments in the VCS settings) or permissions (ensure agents have access to the build tools, like Gradle or Maven, used by your project).

In general, while troubleshooting, do it systematically. For instance, you have to check environment vars if builds fail on missing dependency variables or verify credentials for auth errors. 

Additionally, during your first migration phase, run jobs in parallel (i.e. keep Jenkins active while testing TeamCity). Trigger the build for the same commit in both tools and compare the outputs. This parallel run builds trust and helps you see which tools actually perform better.

Once it’s validated (e.g., after a few successful autotriggered builds) retire the Jenkins job. Disable it first, monitor for a day, then delete. This gradual cutover minimizes risk, letting you roll back if needed.

Conclusion

If you followed along, you just finished migrating a single Jenkins project to TeamCity. You’ve demystified the process, learned more about TeamCity’s intuitive tools, and likely spotted efficiencies like reduced plugin bloat or superior secrets management. This isn’t just a tech swap; it’s a step toward a more reliable, developer-friendly CI/CD.

Now that you’re comfortable, imagine scaling this across your portfolio. TeamCity’s project hierarchies and templates make it easy, but planning is key for larger migrations.

Whether you’re a developer tweaking builds or a DevOps engineer orchestrating workflows, this first win should inspire confidence.