CDK Deploy-Twice: When Your Infrastructure Needs to Know About Itself

**Parâmetros Técnicos: Stop Confiar Cegamente no Código de Inteligência Artificial: Um Estudo de Caso de Refatoração de Código em React**

Olá, meus amigos desenvolvedores! Hoje, vamos discutir um tópico importante que afeta a confiabilidade dos nossos projetos: a importância de revisar e refatorar o código de inteligência artificial (IA) antes de implantá-lo em produção. Vamos analisar o artigo "Stop Trusting AI Code Blindly: A React Code Refactoring Case Study" e discutir os pontos principais.

**Introdução**

A inteligência artificial é uma ferramenta poderosa que pode ajudar a automatizar tarefas complexas e melhorar a eficiência dos nossos projetos. No entanto, é importante lembrar que o código de IA não é infalível e pode conter erros ou bugs que podem afetar a estabilidade do nosso projeto. Nesse sentido, é crucial revisar e refatorar o código de IA antes de implantá-lo em produção.

**Pontos Principais**

1. **Revisão do Código**: A revisão do código é fundamental para identificar erros ou bugs que podem afetar a estabilidade do projeto. Isso inclui a análise de código, a depuração e a teste de unidade.
2. **Refatoração do Código**: A refatoração do código é o processo de melhorar a estrutura e a legibilidade do código existente. Isso pode incluir a reorganização de funções, a remoção de duplicatas e a melhoria da documentação.
3. **Testes de Unidade**: Os testes de unidade são essenciais para garantir que o código funciona corretamente e que os bugs são identificados e corrigidos.
4. **Integração Contínua**: A integração contínua é um processo que permite integrar automaticamente os códigos de diferentes desenvolvedores e garantir que o projeto funciona corretamente.

**Análise do Estudo de Caso**

O estudo de caso apresentado no artigo mostra como uma equipe de desenvolvedores utilizou a refatoração de código para melhorar a estabilidade de um projeto em React. A equipe identificou erros e bugs no código de IA e os corrigiu através da revisão e refatoração do código.

**Conclusão**

Em resumo, é importante não confiar cegamente no código de inteligência artificial e revisar e refatorar o código antes de implantá-lo em produção. Isso inclui a revisão do código, a refatoração do código, os testes de unidade e a integração contínua.

**Convido-vos a Conhecer as Soluções da AplicHost**

Para garantir que os vossos projetos e fóruns rodam sem falhas, convido-vos a conhecer as soluções de alojamento de alta performance da AplicHost em https://aplichost.com. Com a AplicHost, você pode aproveitar as últimas tecnologias e recursos para garantir que o seu projeto seja seguro, escalável e fácil de gerenciar.

CDK Deploy-Twice: When Your Infrastructure Needs to Know About Itself



Tópico: CDK Deploy-Twice: When Your Infrastructure Needs to Know About Itself
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
There is a moment that catches a lot of people out who are new to AWS CDK. You deploy a service, the deploy succeeds, and then you realize the service cannot fully configure itself because it did not know its own endpoint until after it was running.

This is not a CDK bug. It is a genuine chicken-and-egg problem, and once you understand it, the solution is straightforward-ish.



The problem


Some resources only exist after CloudFormation has provisioned them: ALB endpoints, service URLs, and auto-assigned DNS names. These values are not known at the cdk synth time. They are outputs that come back after the stack deploys.

If your application needs to know its own public URL (e.g., to build redirect links), well then, you are in a kerfuffle. You cannot pass a value into the stack that the stack itself has not produced yet. CloudFormation is not psychic, so unfortunately neither is CDK (I hear AI is working on this, though).



What it looks like in practice


Here is a real example from my latest YouTube tutorial video. This is a URL shortener that needs BASE_URL to construct the short links it returns, but BASE_URL is the service's own endpoint, which CloudFormation only assigns after the ECS service and ALB are provisioned.

The CDK stack handles this with tryGetContext:

const baseUrl = this.node.tryGetContext('baseUrl') as string | undefined;

const environment = [
{ name: 'TABLE_NAME', value: table.tableName },
{ name: 'AWS_DEFAULT_REGION', value: this.region },
];

if (baseUrl) {
environment.push({ name: 'BASE_URL', value: baseUrl });
}

And the endpoint is exported as a stack output:

new cdk.CfnOutput(this, 'ServiceEndpoint', {
value: service.attrEndpoint,
description: 'Re-deploy with --context baseUrl=<this value> to wire BASE_URL',
});

`tryGetContext` returns `undefined` if the value was not passed in, so deploy one works fine. It simply runs without `BASE_URL` set. Deploy two wires it in. Therefore, two deploys, one working service, zero existential crises.

The deploy pattern
**Deploy 1:** provision the infrastructure, get the endpoint:

bash

cdk deploy EcsExpressStack

**Deploy 2:** pass the endpoint back in as context:

bash

SERVICE_URL=$(aws cloudformation describe-stacks \

--stack-name EcsExpressStack \

--query "Stacks[0].Outputs[?OutputKey=='ServiceEndpoint'].OutputValue" \

--output text)

cdk deploy EcsExpressStack --context baseUrl=$SERVICE_URL

## Why this is not a CDK bug
CDK synthesizes a CloudFormation template before anything is deployed. At synth time, late-bound values like ALB endpoints exist only as CloudFormation tokens, which are placeholders that resolve later. You can use them within the same stack (they resolve correctly in the template), but you cannot read them back into your TypeScript logic during synth. This is because the template has not run yet, and therefore the value does not exist yet. This is simply the correct order of operations.

`tryGetContext` sidesteps this. You supply the value externally on a subsequent deploy, once CloudFormation has resolved it.

## When you will run into this

- A service that builds URLs pointing to itself
- A resource that needs its own ARN or DNS name as a config value
- Cross-stack references where stack B's input is stack A's output and you have not wired them through `CfnOutput` and `Fn.importValue`

The pattern feels a little awkward the first time. It stops feeling awkward once you understand why it works that way. Then starts feeling awkward again when you dust off that old forgotten side project (you know, that one).

## So which came first: the service or the endpoint?

The endpoint... but only after the service... which needed the endpoint to configure itself... which required the service to exist first.

At this point, I recommend not thinking about it too hard.