From f422c4342c176d033c9418efde0a452b5ef87eca Mon Sep 17 00:00:00 2001 From: Cole Peters Date: Wed, 14 Aug 2024 14:48:57 -0500 Subject: [PATCH] Trim articles not focused on Enhance --- .../2023-09-26-trunk-based-development.md | 217 ------------------ .../posts/2024-03-08-sunsetting-legacy-ci.md | 50 ---- .../2024-06-06-so-we-created-a-new-aws-sdk.md | 23 -- 3 files changed, 290 deletions(-) delete mode 100644 app/blog/posts/2023-09-26-trunk-based-development.md delete mode 100644 app/blog/posts/2024-03-08-sunsetting-legacy-ci.md delete mode 100644 app/blog/posts/2024-06-06-so-we-created-a-new-aws-sdk.md diff --git a/app/blog/posts/2023-09-26-trunk-based-development.md b/app/blog/posts/2023-09-26-trunk-based-development.md deleted file mode 100644 index 80d24ac..0000000 --- a/app/blog/posts/2023-09-26-trunk-based-development.md +++ /dev/null @@ -1,217 +0,0 @@ ---- -title: "Trunk Based Development" -image: "/_public/blog/post-assets/large-tree.jpeg" -image_alt: "Large Tree" -category: enhance, best-practice -description: "Trunk Based Development is the best way to work with teams to build software. TBD means teams work on a single main branch (like the trunk of a tree), and changes are integrated back into that main branch as soon as possible." -author: 'Ryan Bethel' -avatar: 'ryanbethel.png' -twitter: 'ryanbethel' -mastodon: "@ryanbethel@indieweb.social" -published: "September 26, 2023" ---- - - -People often ask what is the best way to manage different development and staging environments on a team. -At [Begin](https://begin.com), we do Trunk Based Development, and we recommend it as a best practice. - - -## Trunk Based Development: TL;DR - -Trunk Based Development (TBD) means teams work on a single main branch (like the trunk of a tree). -Changes are integrated back into that main branch as soon as possible. -This means: - - -* **Changes are released regularly in small increments**. -* **Feature branches are short-lived** and merged back to the main branch as quickly as possible. -* **Longer running features are broken down into smaller tasks** that can be merged into the trunk regularly. -* **Feature flags** are used to release parts of a new feature without users seeing it until it is ready. -* **Continuous Integration** uses automated tests and release processes to make sure that small changes can be released with minimal friction. -* **Avoids nightmare merges** from long-lived feature branches. - - -## How we do TBD - -Trunk Based Development can be implemented in many ways with many different tools. -The details are less critical than the overall approach. -But for those deploying [Enhance](https://enhance.dev) projects on [Begin.com](https://begin.com) (or with [Architect](https://arc.codes) directly to AWS) this is how we do it. - - -Each website has a production and a staging environment with different domains. -When code is pushed to the “main” branch, if tests pass, it is automatically deployed to staging. -When a new Git Tag is created with a semver label, that tagged commit is deployed to the production environment if tests pass. -In other words: - - - -1. `git push main` triggers a GitHub action that runs tests with `npm test` and then deploys to staging with `begin deploy --env staging`. -2. `npm version patch && git push main` triggers a GitHub action that runs tests with `npm test` and then deploys to production with `begin deploy --env production`. - - -### Testing - -The key to testing is to keep it simple to start. -Don't let perfect be the enemy of good. -Anything is better than nothing. -We recommend using something like [tape](https://github.com/ljharb/tape). -Taylor Beseda has written some more recommendations here ([tools-for-testing-functional-web-apps](https://begin.com/blog/posts/2021-12-09-tools-for-testing-functional-web-apps)). -For continuous integration, make sure that the tests can be run automatically (i.e. with GitHub Actions) to prevent accidentally deploying code that does not pass. - - -When you start a new project, a good practice is to add at least one test. -That may be as simple as making a GET request to the site and testing for a 200 response. -With that one test in place, it lowers the barrier to incrementally adding a new test when fixing a bug or adding a feature. - - -### Feature Flags - -Feature flags are a way to incrementally add new features to a site while making sure that users or team members do not see the feature until it is ready for them to try. -To use feature flags, the code for the new and old experience is in a conditional selected by the state of the flag. -It is important to keep the size of the code behind a feature flag as small as possible. -If there are thousands of lines of code on each side of the conditional, you are not really on the trunk anymore. -You are planting a new tree. - - - -```javascript -export function MyPage({html, state}){ - let header - if (featureFlagEnabled("newHeader")) { - header = newHeader - } else { - header = oldHeader - } - return html`${header}` -} -``` - - - - -The second part of feature flags is exposing the feature to only the group of users you want to see it (often called segmentation). -In some cases, that group of users may be team members or a few hand picked users for early feedback. -In this case, it may work to have them take some an intentional action to opt into the new feature(i.e. -query parameters `https://staging.example.com?feature=newHeader`). - - -But many times the segmentation needs to be transparent to users. -We can do this with the user session. -For logged-in users we can assign the feature group in the database (i.e. `{username:"jane", features:["newHeader"]}`). -When the user logs in, the features are added to the session ( i.e. `return {session: {authorized:true, features:["newHeader"]}}`). -The session can also be used to segment non-authenticated users. -When a new request is received, the session is checked for feature flags to see if they are already segmented. -If they are not, new features can be assigned based on segmentation criteria (i.e. 10% randomly assigned). - - -The use of feature flags in large teams or large projects can be complex. -There are many third-party providers that can help manage them (i.e. [Launch Darkly](https://launchdarkly.com/)). -We recommend starting with the simplest thing that can possibly work. - - - -### Continuous Integration - -A critical feature of Trunk Based Development is that it should be easy to release changes. -We use GitHub Actions for automating releases. -The example below shows a streamlined `build.yml` for releasing a website. -Pushing to the main branch will trigger tests and, if they pass, deploy to the staging environment using the begin CLI. -Simon MacDonald wrote more about this process in [Using GitHub Actions with Architect — Begin Blog](https://begin.com/blog/posts/2022-04-22-using-github-actions-with-architect). - - - - -```yaml -name: Node CI - -# Push tests pushes; PR tests merges -on: [ push, pull_request ] - -defaults: - run: - shell: bash - -jobs: -# Deploy the build - deploy_staging: - name: Deploy staging - if: github.ref == 'refs/heads/main' && github.event_name == 'push' # Don't run twice for PRs (for now) - runs-on: ubuntu-latest - concurrency: - group: staging_${{ github.repository }} - - steps: - - name: Check out repo - uses: actions/checkout@v4 - - - name: Set up Node.js - uses: actions/setup-node@v4 - with: - node-version: 16 - - - name: Install - run: npm install - - - name: Run tests - run: npm run test - - - name: Deploy to staging - uses: beginner-corp/actions/deploy@main - with: - begin_token: ${{ secrets.BEGIN_TOKEN }} - begin_env_name: staging - channel: 'main' - -# Deploy the build - deploy_production: - name: Deploy production - if: startsWith(github.ref, 'refs/tags/v') && github.event_name == 'push' # Don't run twice for PRs (for now) - runs-on: ubuntu-latest - concurrency: - group: production_${{ github.repository }} - - steps: - - name: Check out repo - uses: actions/checkout@v4 - - - name: Set up Node.js - uses: actions/setup-node@v4 - with: - node-version: 16 - - - name: Install - run: npm install - - - name: Run tests - run: npm run test - - - name: Deploy to production - uses: beginner-corp/actions/deploy@main - with: - begin_token: ${{ secrets.BEGIN_TOKEN }} - begin_env_name: production - channel: 'main' -``` - - - -### Non-websites - -Most of the examples above deal with websites. -A similar approach can be applied to most types of projects. -For example, if you are developing an NPM package, you can set up GitHub actions CI so that creating a tag will run tests and publish the package to NPM. -For the repo where we develop the `begin` CLI we have GitHub actions set up so that pushing to the main branch creates a release that can be used by team members (the equivalent of a staging), and then tagging will create a production release that users will get by running `begin update`. - - - -## Further Reading - -This post is only a small primer on Trunk Based Development. -You can read more about it, and other related best practices in these resources: - - - -* [Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley-ebook/dp/B003YMNVC0) by Jez Humble and David Farley. -* [Accelerate](https://www.amazon.com/Accelerate-Building-Performing-Technology-Organizations/dp/B07BMBYHXL) by Nicole Forsgren PhD, Jez Humble, and Gene Kim -* [Software Engineering](https://www.amazon.com/Modern-Software-Engineering-Better-Faster/dp/B0BLXCXT3R) by David Farley -* [DORA Reports](https://dora.dev/publications/) diff --git a/app/blog/posts/2024-03-08-sunsetting-legacy-ci.md b/app/blog/posts/2024-03-08-sunsetting-legacy-ci.md deleted file mode 100644 index a5aebad..0000000 --- a/app/blog/posts/2024-03-08-sunsetting-legacy-ci.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Sunsetting Begin’s legacy CI service" -image: '/_public/blog/post-assets/arc57.png' -image_alt: "Sunset" -category: begin -description: "Learn more about how to migrate to Begin Deploy, AWS, or other services" -author: 'Brian LeRoux' -avatar: 'brian.jpg' -mastodon: "@brianleroux@indieweb.social" -published: "March 8, 2024" ---- - -In late 2022 we [announced a next-generation version of our service called Begin Deploy](https://begin.com/blog/posts/2022-08-31-new-begin-and-enhance-html-framework). As part of that announcement we also committed to continuing to keep our legacy CI service (found at ci.begin.com) online in perpetuity for existing users. - -The legacy CI service is an expansive codebase authored around AWS SDK v2. Unfortunately, AWS has deprecated that SDK and is making it unavailable in Lambda environments in a few short months. This means we can no longer operate our legacy CI service without a large rewrite, and as a small startup we unfortunately do not have the resources to do so. - -We would strongly prefer to continue operating our legacy CI service in perpetuity, but due to AWS’s deprecations, we must unfortunately announce that **effective May 1, 2024, Begin’s legacy CI service will no longer be available**. Any applications deployed using that service should migrate to Begin Deploy, AWS, or the service of your choosing. - -**We deeply apologize for any inconvenience this transition may cause.** We understand the challenges that come with changes of this nature and we are committed to assisting you through this transition. - - -## Migrating to GitHub Actions - -For remaining legacy CI users, we recommend migrating to GitHub Actions for your CI/CD needs. GitHub Actions offers a flexible, powerful alternative that integrates seamlessly with your development workflow. You can use GitHub Actions to deploy your app with Begin Deploy, or deploy it directly to AWS, depending on your project's requirements. - -Learn more about [migrating to GitHub Actions](/deploy/docs/additional-resources/legacy-ci-migration). - - -## Migration assistance and resources - -We want to assure you that the migration process will be straightforward. Our platforms have always prioritized backward compatibility and AWS portability, aiming to make transitions as smooth as possible for our users. - -Our team is here to support you through this transition. We are linking documentation and resources to guide you in migrating your CI workflows to GitHub Actions below. Additionally, our team is available via [Discord](https://discord.gg/y5A2eTsCRX) and [email](https://begin-help.zendesk.com/hc/en-us/requests/new) 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! - -- [Learn more about Architect backwards compatibility here](/deploy/docs/additional-resources/legacy-ci-migration#architect-compatibility) -- [Instructions for using GitHub Actions with Begin Deploy can be found here](/deploy/docs/additional-resources/legacy-ci-migration#migrating-to-begin-deploy-%26-github-actions) -- [Instructions for using GitHub Actions with AWS can be found here](/deploy/docs/additional-resources/legacy-ci-migration#migrating-to-aws-%26-github-actions) -- Please [sign up for our Discord ](https://discord.gg/y5A2eTsCRX) and find us in the #begin channel - - -## What happens if you do nothing - -If you do not take any action, any applications deployed with Begin’s legacy CI service will become permanently unavailable on or after May 1, 2024. - - -## How we’re mitigating similar issues in the future - -So as not to be impacted by future deprecations or breaking changes in the AWS SDK, we now maintain our own entirely open source AWS SDK for Node.js called [`aws-lite`](https://aws-lite.org). Learn more about it at [aws-lite.org](https://aws-lite.org). We are presently moving our systems over to utilizing `aws-lite`, and do not expect Begin Deploy to be impacted by any changes or deprecations coming out of AWS JavaScript SDK groups. diff --git a/app/blog/posts/2024-06-06-so-we-created-a-new-aws-sdk.md b/app/blog/posts/2024-06-06-so-we-created-a-new-aws-sdk.md deleted file mode 100644 index 2f20e18..0000000 --- a/app/blog/posts/2024-06-06-so-we-created-a-new-aws-sdk.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "So We Created a New AWS SDK" -image: '/_public/blog/post-assets/aws-lite.png' -image_alt: "aws-lite A simple, fast, extensible AWS client" -category: aws -description: "What if the AWS SDK was really fast? What if it had a much simpler interface, and great error handling? Or built-in debugging output? What if it had its own API for integrating with your unit tests? What if its docs were, like, ok? And what if you could build your own custom plugins?" -author: 'Simon MacDonald' -avatar: 'simon.png' -mastodon: "@macdonst@mastodon.online" -published: "June 6, 2024" ---- - -What if the AWS SDK was really fast? What if it had a much simpler interface, and great error handling? Or built-in debugging output? What if it had its own API for integrating with your unit tests? What if its docs were, like, ok? And what if you could build your own custom plugins? - -Well, now it can: it’s called [aws-lite](https://aws-lite.org/)! Learn more about why we built our own open source AWS SDK, and whether a new AWS SDK is right for you in this illuminating presentation by [Ryan Block](https://mastodon.social/@ryan). - -## Video - - - -