Legacy CI migration

Due to the deprecation of AWS SDK v2, unfortunately it is no longer possible for Begin to operate its legacy CI service (ci.begin.com). (Learn more here.) Applications deployed using that service should migrate to Begin Deploy, AWS, or the service of your choosing prior to May 1st, 2024.

This document will outline general information, considerations, and steps for migrating to Begin Deploy or AWS.

Overview

Begin’s legacy CI system provisioned and deployed Architect applications that were connected to GitHub repos. Once set up, the legacy CI service accepted GitHub push and tag events to kick off deployments.

However, Architect apps can still be shipped with Begin Deploy or directly to AWS, usually with minimal or no modification to business logic.

At its core, migrating away from Begin’s legacy CI system means provisioning a new app based on your existing codebase with either Begin Deploy or AWS. (If continuing to use Begin, this will mean a new begin.app URL.) Domains are be covered below.

Please review the following compatibility and migration considerations for apps deployed with the legacy CI system.

Architect compatibility

Begin’s legacy CI system ships Architect apps, and the Architect framework has long endeavored to ensure maximal backward compatibility. Architect apps authored years ago still properly run and deploy today with minimal fuss.

The legacy CI system deployed Architect 5.x-era applications, so you are strongly encouraged to review Architect’s upgrade guide, starting at v5 to 6, to learn about what’s changed.

A few key things to note:

  • If you authored your @http Lambdas with @architect/functions, simply upgrading to the latest Functions will likely ensure complete compatibility with current-generation Begin Deploy and AWS infrastructure, such as API Gateway HTTP APIs
  • Try installing the latest version of Architect (npm i @architect/architect@latest) and, if used, @architect/functions in your project; then run npx arc sandbox to begin validating your app’s functionality
    • If your project runs well in Sandbox, it will probably work just fine as-is in Begin Deploy or AWS

General migration considerations

  • If your app makes use of Begin Data, you have a couple of paths available. First, you will create a new app with Begin Deploy or on AWS (further instructions below), then either:
    • Download your old app’s data, and write that data into your new app (via an API endpoint), or
    • Contact Begin support to set up a managed migration
  • If your app uses a custom domain, please see our custom domains section below
  • If your app uses package[-lock].json files in each handler folder, those are no longer necessary
    • Do leave the project-level package[-lock].json file(s) in your project’s root directory, though
  • If you do not migrate your application, it may become permanently unavailable on or after May 1, 2024

Custom domains

If your legacy app uses a custom domain, you will likely need some amount of support from the Begin team. We are here to help you ensure the timely migration of AWS resources necessary to maintain the availability of your domain, please reach out to us directly.

Migrating to Begin Deploy & GitHub Actions

Migrate to Begin Deploy with GitHub Actions in the following steps:

  • Review the compatibility and migration considerations noted above
  • Install the Begin Deploy CLI
  • Run begin login to authenticate with Begin
  • Run begin dev and validate your application’s functionality
  • Run begin deploy to create a new staging environment and deploy your app to it
  • As appropriate, validate your application’s functionality in your staging environment
  • Commit and push changes to your [app].arc file that include the @begin pragma and appID item
  • Create and deploy to a production environment, as necessary
  • Ensure GitHub Actions is enabled for your repository (ref)
  • Follow the directions found in the Begin Deploy GitHub Actions guide

Migrating to AWS & GitHub Actions

Migrate to AWS with GitHub Actions in the following steps:

  • Review the compatibility and migration considerations noted above
  • Review and follow the Architect detailed AWS setup guide
  • Run npm i @architect/architect@latest to install the latest version of Architect to your project
  • Run npx arc deploy to create a new staging environment and deploy your app to it
  • As appropriate, validate your application’s functionality in your staging environment
  • Create and deploy to a production environment, as necessary
  • Ensure GitHub Actions is enabled for your repository (ref)
  • Implement a GitHub Actions yaml file as you see fit, and deploy using the Architect deploy action

Post-migration

Once completed with your migration, no further action needs to be taken at ci.begin.com; on or after May 1, 2024, resources will be automatically removed, and existing URLs will be deactivated.

Getting support

Our team is here to support you through this transition; we are available via Discord and email during regular business hours (PT / MT time) to answer any questions and assist with any challenges you may encounter during the migration process.

We look forward to assisting you through this transition and thank you for your understanding, patience, and continued support!