タグ

ブックマーク / studist.tech (10)

  • MacのDocker Desktop代替としてRancher DesktopとPodman Desktopを試して諦めた話

    どうも。最近Dockerのことばかり書いてるビジネステクノロジーユニットのおかしんです。今回はDocker Desktopの代替としてRancher DesktopPodman Desktopを試したのですが、それぞれ解決できない問題があり諦めた話をします。

    MacのDocker Desktop代替としてRancher DesktopとPodman Desktopを試して諦めた話
  • Personal Access TokenからGitHub Appsに移行する

    スタディスト開発部の松野です。最近GitHub Actions上でGitHub GraphQL APIを使って情報を取得する機会が多くありました。そこでGitHub Appsなるものを知り、使ってみたのでその紹介をしたいと思います。 結論(TL;DR)GitHub Actions から GitHub API を叩く際の認証と認可でどの仕組みを使うか検討したPersonal Access TokenやOAuth Appを使うと、ユーザー個人に紐づく仕組みのため色々やり辛い社内用の GitHub Appsを作成し、そのPrivate keyからAccess Tokenを生成する方法で解決GitHubと連携するための仕組みGitHubには、作成しているツールとGitHubとの連携を容易にする仕組みとして、GitHub Apps、OAuth App、Personal Access Tokenがあり

    Personal Access TokenからGitHub Appsに移行する
  • Docker Desktopの有料化が企業に与える影響と、企業における適切なDockerの利用方法

    Photo by Mohammad Rahmani on Unsplashどうもビジネステクノロジーユニットの @おかしん です。 今や世の中のあらゆるシステムの開発現場においてコンテナ技術は無くてはならないものになっています。コンテナ技術の中で最も広く利用されているのはDockerコンテナですが、昨年オープンソースソフトウェアであるDockerを開発しているDocker社が「Docker Desktop」というアプリケーションを有料化しました。 そこで、企業においてはどのように対応すべきか?また回避策はあるのか?を考えてみました。 Docker Desktopとは何かDocker DesktopDocker社が提供しているソフトウェアでオープンソースソフトウェアであるDockerWindowsMacOSにおいて簡単にインストールし利用できるアプリケーションです。 DockerはLi

    Docker Desktopの有料化が企業に与える影響と、企業における適切なDockerの利用方法
  • tfmigrate on GitHub Actions を導入して state の操作フローを改善する

    Photo by Christopher Gower on Unsplashこんにちは、SRE Unit の wind-up-bird です。少し前に Terraform Cloud から GitHub Actions に移行したお話というタイトルでブログを書きました。今回はその後日談を少し紹介したいと思います。 # これまでの state 運用今までは Terraform の state の操作は手動で実施していました。具体的には、terraform import, state mv, state rm をローカルで実行した後、PR を作成して state と tf ファイルの差分を埋めるという運用でした。 # 課題ここで以下のような問題が出てきます。 誰がどのような state 操作をした(しようとしているか)分からない。また、誤操作してしまう可能性もある。PRのレビュー後 tf ファ

    tfmigrate on GitHub Actions を導入して state の操作フローを改善する
  • 社内ツール kyafuコマンド の紹介

    kyafu呼び出しに対する応答画像はSlack上でkyafu deployコマンドが叩かれている様子です。work1–10のどのインスタンスを利用するのかと検証したいブランチ名を指定しています。 構成を簡単に示すと以下のようになります。 簡易な構成図InfraやCI/CDについての知識がほとんどなかった私にとって、kyafuは魔法のコマンドでした。簡単に検証環境のデプロイや起動ができ、実行完了後に通知まで送ってくれるのでとても便利です。 ですが、当時のkyafu(というか検証環境の運用)には課題感もありました。それは、使用する環境の衝突が起きないように調整する必要があったことです。 大体どのチームがどの番号のインスタンスを使うのか、までは決まっていましたが、同一チーム内に検証したい機能が複数あった場合、検証用のインスタンス数に限りがあるため、待ちが発生することがありました。 Kuberne

    社内ツール kyafuコマンド の紹介
  • Terraform Cloud から GitHub Actions に移行したお話

    スタディスト開発ブログ Advent Calendar 2021の13日目の記事です。 こんにちは、SRE Unit の wind-up-bird です。以前、 Serverless Framework を移行しているお話を書きましたが、今回は移行シリーズ第2弾ということで、 Terraform Cloud を Terraform on GitHub Actions に移行したお話をお届けしたいと思います。 # 移行前の運用スタディストではこれまで Terraform Cloud の Team & Governance プランを契約していました。移行前の Terraform による開発の流れは、以下のとおりです。 Terraform Cloud 上で Workspace を作成し、Version control workflow を利用する。Workspace には環境変数として、 AWS

    Terraform Cloud から GitHub Actions に移行したお話
    fumikony
    fumikony 2021/12/13
  • Serverless Framework から lambroll + Terraform に移行しているお話

    はじめまして、wind-up-bird です。スタディストの SRE Unit に入ってから約半年が経ちました。今回は社内で利用している Serverless Framework を lambroll に移行しているのでその話を少し書いてみようと思います。 これまでの開発の流れスタディストでは AWS Lambda および周辺リソース(AWS IAM や Amazon API Gateway など)の管理はこれまで Serverless Framework を利用していました。開発からリリースの流れは以下の通りです。 Lambda の開発serverless.yml を作成開発者がデプロイ担当者に連絡する担当者がローカルの環境から serverless deploy を手動実行Serverless Framework 導入当初は管理しているリソースが少なくこの運用でもあまり問題になりません

    Serverless Framework から lambroll + Terraform に移行しているお話
    fumikony
    fumikony 2021/10/27
  • 機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス

    スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。 2021年上半期、およそ6万行の JavaScript コードを TypeScript に置き換える作業を、半年間単独で行いました。 記事では、機能開発自体を止めずに、どのように走り切ることができたのか、ふりかえりたいと思います。 なお、記事の内容は、移行開始直後の登壇資料 “大規模 Vue アプリケーションの TypeScript 移行” と、移行完了後の登壇資料 “6万行の TypeScript 移行とその後” と重複する内容を含んでいます。 Teachme Biz と TypeScript弊社が開発している、マニュアル作成・共有システム Teachme Biz は、iOS/AndroidWindows など、マルチプラットフォームで提供されています。 その中でも、作成・管理に多く使われて

    機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス
  • 「信頼」がQAの価値を生む

    こんにちは、QAグループマネージャーの岩崎です。 以前「モダンなQA組織を目指して」という記事を投稿してから、ブログみたよ!と連絡を貰えることがあり嬉しく思います。 今回はQA組織の成長、QAエンジニアとして成長するために意識してきたことや、普段行っている業務や考え方を整理し、「QAの価値」と「QAにとって重要な要素」を言語化した話をします。 前提:顧客価値を正しく提供するためのQA前提としてスタディストQAにおける品質についての話をします。 スタディストQAでは「顧客価値」を重視した品質活動をしています。 そのため下流のテスト活動にとどまらず、上流での品質担保を試行錯誤し、「顧客価値」を正しく提供・担保できるように日々尽力しています。 当然下流におけるテスト活動も重要ではありますが、上流工程でのアプローチが「顧客価値」を提供する上で最も重要だと考えているためです。 その上流工程での作業を

    「信頼」がQAの価値を生む
  • スタディスト開発部が目指す SRE の未来と現状と Kubernetes

    (上記ブログ執筆時は、EKS on EC2 へ移行予定でしたが、EKS on Fargate への移行を行う方針に切り替えました。) Kubernetes 移行に関連する技術面の話題についてはご紹介してきた一方で、これまでの記事では、 「なぜ Kubernetes 移行を行っているか?」「スタディスト開発部は、最終的に何を目指しているのか?」といった背景には触れておりませんでした。そこで記事では、スタディスト開発部が目指す世界観と、その過程として歩んでいる Kubernetes 移行の位置づけについてご紹介します。 目次Teachme Biz における Infra の現在と抱えている課題スタディスト開発部が目指す世界観Kubernetes 移行の位置づけ今後のやりたいことTeachme Biz における Infra の現在と抱えている課題現在 Teachme Biz の大部分(以降、

    スタディスト開発部が目指す SRE の未来と現状と Kubernetes
  • 1