Pythonでの開発・CI/CDの私的ベストプラクティス2022
はじめに 2021年、Pythonで複数の暗号系ライブラリを開発してPyPIで公開してきました。その過程で、setuptools、flit、poetryと、幾つかのパッケージ管理をわたり歩き、GitHub上でのCI/CDも色々試す中で私的なべスプラが定まってきたので、2022年初に備忘録としてまとめておきます。 具体的には、pyenv、poetry、pre-commit、tox、GitHub Actions を活用し、低コストで（＝なるべく自動で）、高品質のプロダクトをPyPIにデプロイする方法・設定を共有します。個別のツールの記事はよく目にするのですが、開発ライフサイクル全体をカバーする記事がなかなか無かったので。 開発環境の整備 - pyenvで複数のPythonバージョンでの開発環境を整備 パッケージ管理 - poetry/pyproject.tomlでの一元的なパッケージ管理 静的
Terraform の CI に tfmigrate を導入した話 - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Monorepo の CI にtfmigrate を導入した話を紹介します。 なお、弊社の Terraform Monorepo に関しては過去の記事も参照してください。 Terraform リポジトリをマージして CI/CD を改善した話 - スタディサプリ Product Team Blog Pull Request の terraform plan の実行結果を S3 に保存して安全に apply - スタディサプリ Product Team Blog Terraform の CI/CD を CodeBuild に移行した話 - スタディサプリ Product Team Blog tfmigrate とは tfmigrate とはなにかについては、 tfmigrate の作者様がこちらの記事で詳し
サイエンティストとエンジニアでつくるML ワークフロー - スタディサプリ Product Team Blog
こんにちは、データエンジニアの@masaki925 です。 この記事はMLOps Advent Calendar 2020 の19 日目の記事です。 MLOps には、その成熟度に応じて3つのレベルがあると言われています。 MLOps レベル 0: 手動プロセス MLOps レベル 1: ML パイプラインの自動化 MLOps レベル 2: CI / CD パイプラインの自動化 私の所属するチームでは現在ここのレベルを上げるべく取り組んでいますが、その中でデータサイエンティスト(以下、DS) とデータエンジニア(以下、Dev) の協業って難しいよな〜と思う事例があったので紹介したいと思います。 想定読者は以下のような方です。 これからMLOps を始めようとしている方 既存プロジェクトがあり、ML 等を使ってエンハンスしていきたいと考えている方 異文化協業に興味がある方 ML ワークフロー
minfront: フロントエンド実験用のSPAボイラープレート - mizchi's blog
なんでそんな手が速いのか聞かれたので、最近使ってるSPAボイラープレートを紹介しておきます。 github.com $ git clone git@github.com:mizchi-sandbox/minfront.git --depth 1 myspa $ cd myspa $ yarn install $ yarn dev # Start app server 終わり。 src/main.tsx か src/index.html を編集して、 yarn build && yarn deploy で netlify にアップロードできます。(要 netlify アカウント) こんな感じ https://gallant-yalow-997008.netlify.com プロダクションで使えるちゃ使えるかもしれないけど、議論の余地があるようなものを含まない最小構成。 含まれるもの yarn
DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い
両氏はこのプレゼンテーションの中で、それぞれの役割の違いから対立することの多い開発者（以下、Dev）と運用者（以下、Ops）の対立構造を次のように示した。 Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた。 しかしDevとOpsのそれぞれのミッションは（DevOpsの概念と同じく）、どちらも「システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」ことである。そのミッションを達成するための手段が、上記のとおりDevは“システムに新しい機能を追加する”であり、Opsは“システムの安定稼働”なのである。つまり、同じ「ミッション」を掲げている
チーム開発実践入門──共同作業を円滑に行うツール・メソッド
この書籍に関連する記事があります！ はじめに 本書は「チーム開発実践入門」です。読者のみなさんの中にはよくご存じの方も多いかとは思いますが，チーム開発というのは複雑で難しいものです。 チーム開発を円滑に行うには 本誌の読者の中にソフトウェアやサービスの開発を仕事にしている方もいるかと思います。 第1章 チーム開発とは 1.1 1人だけでも開発はできる 1.2 チーム開発で直面する課題 1.3 どのように課題に立ち向かうか 1.4 本書の構成 第2章：ケーススタディ 第3～5章：基礎的なプラクティス 第6～7章：継続的デリバリーとリグレッションテスト 1.5 本書を読む前の注意点 最適なプラクティスはケースバイケース どのツールを使うかに正解はない 第2章 チーム開発で起きる問題 2.1 ケーススタディの前提 プロジェクトの前提条件 2.2 ケーススタディ（1日目） 問題1：重要なメールが多
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Startup ゼミ 2021 秋期講習 / AWS Startup Seminar 2021 Autumn class - AWS Dev Day
CI details in Kubernetes
Dockerと継続的インテグレーション