In 2017, Target announced that we had prioritized stores at the center of how we serve our guests – no matter how they choose to shop. To make this store-as-hubs model work, we spent several years redesigning operations and modernizing how we conduct business. We invested billions of dollars into remodeling stores, hardened our world-class supply chain, and created a robust suite of fulfillment options to meet every guest need.

Across Target.com and nearly 2,000 stores, we run a complex and highly distributed point of sale (POS) ecosystem. And as we invest heavily in a great omnichannel POS experience, we continue to develop and scale new features for a variety of applications including store registers and self-checkout, our team members’ handheld myDevices, and our award-winning guest mobile app. As a result, we manage more software with a growing number of interactions – a single scan of an item during checkout could mean touching a distributed tree of dozens of services, with hundreds of thousands of these done per minute.

The digital catalog team at Target is responsible for a collection of nearly 100 aggregated APIs to provide browse data for Target.com and mobile app platforms. In early 2019, we were just coming off a large backend migration which meant we would need to version a lot of these APIs. This was a huge effort for all teams involved in standing up and moving to new API versions. With the volume of APIs that needed testing, we needed a solution that would scale and allow our teams to move more quickly.

At Target, we’re guided by one important purpose: to help all families discover the joy of everyday life. That quest to bring joy is at the center of every business decision we make and technology we build.

This post is the second in a two-part series about creating a documentation workflow for data scientists and engineers. Click here to read the first post. This is an adaptation of a presentation delivered to conferences including Write the Docs Portland 2020, Ohio Linuxfest OpenLibreFree 2020, and FOSDEM 2021. The presentation source is available at GitHub and recordings are available on YouTube.

This is an adaptation of a presentation delivered to conferences including Write the Docs Portland 2020, Ohio Linuxfest OpenLibreFree 2020, and FOSDEM 2021. The presentation source is available at GitHub and recordings are available on YouTube. This is a two-part post that will share both the requirements and execution of the documentation workflow we built that is now used by many of our teammates and leaders. Read part two here.

How we chose and implemented an effective model to generate embeddings in real-time.

Target has spent the last several years modernizing our technology stack and advancing our in-house development capabilities. We’ve grown to a global team of over 4,500 incredibly talented technologists and created a culture of testing, learning, and agile processes to great success. This journey has led to an uptick in fantastic new homegrown innovations that help make Target a joyful place to shop and work.

This blog is cross posted from LinkedIn and has been edited for length.

We recently introduced Target’s cybersecurity tool “Merry Maker” and open sourced the framework to help others protect against digital skimming. Here’s a deep dive into how the solution works and how we built it.

Credit card skimmers are custom-made additions to payment devices (like ATMs or gas pumps) that criminals build and use to steal a consumer’s payment information. The threat also exists in digital form, as malicious code covertly inserted into websites to steal credit card information. And with many more people shopping online, protecting against digital skimmers is more important than ever.

One of the most unique and rewarding opportunities for Target engineers is the ability to experience first-hand the impact of their work. The code we develop doesn’t just sit on a backend or behind apps. It runs in over 1,900 stores and shapes how 350,000+ team members operate and countless guests shop.

Our team within Engineering Enablement serves our engineers so they can build the technology products that are used every day by our guests, team members, and partners. One way to do that successfully is to look for sources of friction that slow engineers down and find ways to reduce them. Case in point – our own GitHub pull request workflow for reviewing our colleagues’ changesets. Our monorepo contains 28 packages of varying scopes, from user-facing command-line tools, componentry, and configuration to documentation sites, internal modules, and tumbleweeds of dependencies.

This past July, Target tech celebrated the first 24 team members to complete our Emerging Engineers Program. It was an important moment in time to recognize that there’s no traditional way to start a successful engineering career at Target.

At Target we’re always evolving our business to meet the needs of our guests and team members — which means we’re also always evolving how we build technology. But even though technologists work in an environment that is rapidly changing and advancing, it can often take a long time (sometimes even years) to get to a point where we can retire legacy systems. I wanted to dig into why and explore shimming as a solution to help.

When containers become unhealthy in production environments, a nuclear action is often the best option. When it comes to a security alert however, a different approach is needed. Nuclear actions have been the default answer for too long – there are better ways to handle the encompassing analysis, visibility, and containment for a container that can benefit security analysts in the process. We saw a gap in industry resources that covered these parts in a whole and in the context of analysis and containment... so we created a cumulative resource for our use at Target tech, and wanted to share it out with the community.

How embedding as a software engineer results in learning and empathy.

Open Source GoAlert Is Now Available At https://github.com/target/goalert

Our team developed a service that reads from a Kafka topic, interacts with a Postgres database using basic CRUD operations, and calls APIs on an external service. As part of our increased focus on automated testing, getting to a higher level of testing code coverage required us to tie in the external components of our system architecture. Since we don’t control these components in production, we included these components in our CI/CD pipeline to give us a higher level of confidence that our integrated code is working as expected. We also wanted to run automated functional tests against our service, and that too required running these services in the pipeline. We use Drone as our CI/CD tooling and decided to learn how to use services in Drone to solve this problem. This short blog post runs through an example of how we started up a database service and a Kafka service in Drone and ran a test against these service, that might help others in a similar situation.

What is a Game Day?

Cross-site scripting has been an OWASP Top 10 classic for more than a decade, but it still comes as a surprise to find it out in the wild, especially in a well-known product. During a recent penetration test, Target's Security Testing Services team found that Microsoft's SharePoint was vulnerable to a unique attack that, unlike typical cross-site scripting, could be exploited without any interaction from the victim user.

A few years ago, Target started a journey to move into a product-based organization with dedicated, durable, full-stack teams. One core belief we rallied behind was that product teams were accountable for building, running and supporting their products. Gone were the days of siloed development and operations teams. When a team introduces any change into production, it is accountable for supporting that change for as long as it lives.

Chaos engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.principlesofchaos.org

Scalable, nimble and efficient are terms commonly used to describe microservices, and as such, services are built to meet specific needs based on user features or application requests. However, when services need to communicate among one another, this can become somewhat convoluted and can lead to a significant amount of technical debt if not managed effectively. Target was faced with such a scenario in which it owned 40+ Spring Boot services and service-to-service communication was necessary to ensure service handoffs and SLAs were met. This post will walk through our implementation of Spring Feign Client, our learnings, and how Spring Feign Client has helped manage our inner-service communication while reducing the amount of development time.

Stateful Apps in a Stateless World

At the beginning of 2017...

This blog post is a follow-up to a presentation given at Fastly's Altitude NYC conference on April 17, 2018.