开发者

submitted by /u/fagnerbrack [link] [留言]

Picture this: You just spent weeks building an awesome new feature. It's fully tested and ready to go. But when you hit "Deploy," your entire application goes down for 5 minutes, and your users are met with a blank loading screen. Not a good look. In the world of DevOps and Cloud Infrastructure, how you roll out updates matters just as much as the code itself. AWS Elastic Beanstalk gives us 5 distinct deployment policies to handle this smoothly. Let's break them down from simplest to most robust so you know exactly which one to pick for your next project. 1. All at Once (The Speed Demon) This is the simplest method. Elastic Beanstalk takes all your existing servers, shuts them down, deploys the new code, and boots them back up simultaneously. [ Old App ] ─> SHUTDOWN ALL ─> DEPLOY NEW ─> [ New App ] The Good : It’s incredibly fast. The Bad : Your app goes completely offline during the deploy. When to use it : Only in development environments where downtime doesn't matter. Never use this in production! 2. Rolling (The Line Worker) Instead of updating everything at once, Beanstalk splits your servers into batches (e.g., 2 at a time). It takes the first batch offline, updates them, brings them back online, and then moves to the next batch. Batch 1: [ Updating... ] Batch 2: [ Running Old App ] Batch 1: [ Running New App ] Batch 2: [ Updating... ] The Good : No total downtime! Your app stays online. The Bad : While a batch is updating, your overall server capacity drops. Plus, users might experience a "mixed state" where refreshing switches them between the old and new version. When to use it : Production environments that can handle a temporary dip in bandwidth. 3. Rolling with Additional Batch (The Safe Substitution) To fix the capacity problem of standard rolling, this policy launches a brand new batch of instances first. Once those new servers are healthy and running the updated code, Beanstalk starts rolling the update through the old servers. [Old Servers: 100% Capa

Your docs should build themselves You write your documentation in Markdown. You keep it in a Git repo. Every time someone updates a spec or runbook, someone else has to open PaperQuire (or the CLI), render the PDF, and upload it somewhere. That manual step is now gone. The PaperQuire Render Action generates branded, print-ready PDFs directly in your GitHub Actions workflow — on every push, every PR, or every release. One step. That's it. - uses : paperquire/render-action@v1 with : files : ' docs/*.md' template : executive-report output : build/pdfs Every Markdown file matching the glob is rendered to PDF using the same Chromium engine as the desktop app. Same templates, same quality, no Pandoc or LaTeX to install. What you can build Auto-generate docs on push Whenever someone pushes to docs/ , produce fresh PDFs and attach them as build artifacts: name : Generate PDFs on : push : paths : - ' docs/**/*.md' jobs : render : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : paperquire/render-action@v1 with : files : ' docs/*.md' template : minimal-clean output : build/pdfs - uses : actions/upload-artifact@v4 with : name : pdfs path : build/pdfs/ Team members download the latest PDFs from the Actions tab. No Slack messages, no "can you re-export this?" Attach PDFs to releases Ship documentation alongside your code: - uses : paperquire/render-action@v1 with : files : ' docs/*.md' template : executive-report output : dist/ - name : Upload to release env : GH_TOKEN : ${{ github.token }} run : gh release upload ${{ github.event.release.tag_name }} dist/*.pdf Every release automatically includes the latest versions of your specs, guides, and reports. PR previews Use the action in pull request workflows so reviewers can download rendered PDFs before merging: on : pull_request : paths : [ ' docs/**' ] jobs : preview : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : paperquire/render-action@v1 with : files : ' docs/*.md' output : preview

Have you ever opened an old Laravel 5 project and felt like you were walking into a house where every...

submitted by /u/patrickdevivo [link] [留言]