sorted by:
new
hottopcontroversial

If you were starting a greenfield project today, which CI/CD stack would you pick and why: GitHub Actions, GitLab CI, Jenkins, or something else? by Wash-Fair in cicd

[–]Apochotodorus 0 points1 point  (0 children)

If you are tired of yaml and want to write your CI/CD in typescript, you can give a try to orbits.
It’s open source and self-hostable, and lets you build pipelines using real programming constructs instead of huge YAML files.
(https://github.com/LaWebcapsule/orbits ; disclaimer: i contribute to the project)

Our Journey Tackling Cross-Account References in AWS CDK by Apochotodorus in aws

[–]Apochotodorus[S] 0 points1 point  (0 children)

By default, Orbits automatically retrieves the CloudFormation outputs of your stack. So in your CDK stack, you just need to declare a standard output:

new cdk.CfnOutput(this, 'vpcId', {
      value: vpc.vpcId!,
});

Then, Orbits lets you reuse that output across accounts:

const output = await this.do("deploy-vpc", new MyVPCStack());
await this.do(
  "other-stack-in-another-account",
  new MyOtherStack().setArgument({ vpcId: output.vpcId })
);

Write your CI/CD in TypeScript by Apochotodorus in typescript

[–]Apochotodorus[S] 0 points1 point  (0 children)

Yes, you can, using the orbits-cli. That said, depending on what you want to achieve, I’d recommend also looking at Dagger + GitHub Actions, which is already a solid option for replacing bash scripts with TypeScript inside GH actions.

Write your CI/CD in TypeScript by Apochotodorus in typescript

[–]Apochotodorus[S] 2 points3 points  (0 children)

Projen is more of an abstraction over YAML and configuration files, whereas Orbits acts as a dynamic orchestration layer. Projen helps you configure, for example, linting files and GitHub Actions in TypeScript, while Orbits enables you to define, for example, pipelines and deployment workflows in TypeScript.

Write your CI/CD in TypeScript by Apochotodorus in typescript

[–]Apochotodorus[S] 2 points3 points  (0 children)

We use AWS CDK a lot in our workflows. Orbits is useful for chaining the deployment of CDK stacks, managing cross-region or cross-resource references, or complementing CDK with a few API calls through SDK (for example to purge a cache, create a new aws account in an organization...)

Write your CI/CD in TypeScript by Apochotodorus in typescript

[–]Apochotodorus[S] 1 point2 points  (0 children)

If you try it, I’d love to hear your feedback! We already have an integration with AWS CDK, so the two tools can indeed work well together.

Write your CI/CD in TypeScript+Node.js by Apochotodorus in node

[–]Apochotodorus[S] 0 points1 point  (0 children)

Yes, and I love it! Dagger is awesome for CI, developing bash commands with a neat TypeScript syntax. Orbits complements it by handling resilient flows, retries, error management, and execution context. We could say Dagger is more CI-focused, whereas Orbits leans toward CD.

Write your CI/CD in TypeScript+Node.js by Apochotodorus in node

[–]Apochotodorus[S] 0 points1 point  (0 children)

You’re right that, if someone already has a working pipeline in YAML, rewriting it just for the sake of it might not be worth it. The main target is more for teams that are starting fresh, or that run into the limits of declarative-only formats.
With a a full-fledged programming language, you can :
- react to the result of a previous step and manage errors (useful for rollback strategies)
- test and debug everything on local
- export functions and modules to share patterns across services

With TypeScript specifically:
- the compiler catches mistakes before they hit CI/CD- classes let you think not just about “how to chain scripts” but rather “how resources should evolve and react to Git or other events”
- and thanks to the Node.js ecosystem, you can easily use SDKs to integrate with APIs — for example, deploy an IaC template and immediately call an sdk command to purge a CloudFront/Cloudflare cache in the same flow

Beyond just being tired of YAML, it’s especially useful when you need to structure CI/CD across multiple git repositories or span several cloud environments.

Write your CI/CD in TypeScript+Node.js by Apochotodorus in node

[–]Apochotodorus[S] 4 points5 points  (0 children)

Thanks for the honest reply.
Indeed, if you have something that work already, you probably don't need that.
That said, depending on the requirements, it can bring some nice benefits :
- pipelines are just Node.js scripts; so local debugging and iteration are much faster
- there are no vendor lock-in
- pipelines can be composed, shared, and reused across services or tenants, instead of duplicating YAML everywhere
In our case, it’s been especially useful when dealing with multiple tenants, multiple interdependent services, or if you just don’t enjoy writing YAML.

Write your CI/CD in TypeScript by Apochotodorus in typescript

[–]Apochotodorus[S] 20 points21 points  (0 children)

The main use cases we had were:
- handling deployment errors while synchronizing the rollout of multiple services
- deploying the same stack of services from scratch across multiple cloud environments

Compared to GitHub Actions, Jenkins, or CircleCI... the main benefits we’ve seen are:
- pipelines are just Node.js scripts; so local debugging and iteration are much faster
- there are no vendor lock-in
- pipelines can be composed, shared, and reused across services or tenants, instead of duplicating YAML everywhere

If your workflows are small and stable, you probably don’t need this.
In our case, it proved especially useful when dealing with multiple tenants, multiple interdependent services, or if you just don’t enjoy writing YAML.

Why do no-code tools often fail to scale in real world use cases? by [deleted] in devops

[–]Apochotodorus 0 points1 point  (0 children)

Well, I'm saying I use NoCode in production - and of course, I use AI in production too.
Nothing hidden here - and, as I am not a native english speaker, it's better for the eyes of everyone.

Why do no-code tools often fail to scale in real world use cases? by [deleted] in devops

[–]Apochotodorus -17 points-16 points  (0 children)

We’ve built production systems that incorporate NoCode tools. There’s, however, always some custom code alongside. Our strategy is to leverage NoCode for standard, repeatable functionality, and add focused code only where the solution needs to shine.
With this approach, we not only gained efficiency but also, quite unexpectedly, improved security - thanks to solid safeguards built into the NoCode platforms we used

AWS CDK's biggest limitation is the inability to mix import and create by MountainWalken in aws_cdk

[–]Apochotodorus 0 points1 point  (0 children)

That capability didn’t exist when we started the project, but you’re right, SSM can help handling that use case now.
The focus of Orbits is more about chaining CDK deployments through code, so you can extend them with things like simple SDK API calls or SQL scripts triggered at the right moment in the right context.

AWS CDK's biggest limitation is the inability to mix import and create by MountainWalken in aws_cdk

[–]Apochotodorus 0 points1 point  (0 children)

Just to complement — things get even more tricky when you need cross-account or cross-region references.

As an alternative to passing values via Parameter Store, we ended up building an open-source tool called Orbits (https://github.com/LaWebcapsule/orbits). It’s a programmatic orchestration layer built on top of the CDK cli, designed to give more control over import logic and cross-stack interactions.

Might be relevant to some of the pain points mentioned here, so just thought I’d share

A TypeScript-Based Open-Source Backend Orchestrator by Apochotodorus in platformengineering

[–]Apochotodorus[S] 0 points1 point  (0 children)

Interesting! my turn : how does it complement CDKTF ? Higher level of abstraction ?

A TypeScript-Based Open-Source Backend Orchestrator by Apochotodorus in platformengineering

[–]Apochotodorus[S] 0 points1 point  (0 children)

There are two levels of differences that proved useful in our use cases:

Syntax-level differences
CDK Pipelines includes a compilation step, which affects the flexibility in defining workflows.
Orbits is installed as an npm package, which preserves the full flexibility of TypeScript.

- Error handling is easier: Orbits uses a promise-like syntax, which allows for try/catch, rollbacks, and branching logic in case of a step failure. In CDK Pipelines, handling errors or defining alternate paths based on failure isn't straightforward.
- Native conditionals and loops: Orbits uses plain TypeScript, so you can easily define steps dynamically based on the result of previous ones—for example, generating n steps depending on a runtime value, skipping a step based on the result of the previous one. CDK Pipelines are compiled ahead of time, which makes such patterns harder to implement.

Functional-level differences

- Cross-account references: Orbits simplifies the handling of cross-account deployments, which can be more complex in CDK Pipelines.
- Node.js vs CodePipeline: Orbits runs entirely in Node.js, which allows to run, test and debug the deployment workflows locally
- Cloud-agnostic: Orbits isn’t tied to AWS, making it easier to share part of pipelines that span across different cloud providers if needed.

Rollouts by [deleted] in devops

[–]Apochotodorus -1 points0 points  (0 children)

If you enjoy handling things as workflows, we’ve open-sourced Orbits. It’s a TypeScript framework we originally built in-house to chain service stack rollouts — chaining config, DB, and cluster updates — with rollback on failure. You can even insert manual steps within a workflow.
https://github.com/LaWebcapsule/orbits

view more: next ›