Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

こんにちは!ピクシブ福岡オフィスでエンジニアをしている@tasshiです。 今回はpixiv insideリニューアルのデプロイ環境についてお話ししたいと思います。 pixiv insideについて 「pixiv inside(ピクシブ インサイド)」は、ピクシブ株式会社の日常を伝えるためのオウンドメディアです。 2014年に「pixiv engineering blog」としてスタートし、2017年に現在の「pixiv inside」になりました。 WordPressからはてなブログへ pixiv insideでは2020年1月にセルフホスティングのWordPressからはてなブログへと移行し、新デザインへのリニューアルを行っています。 デザインリニューアルではデザイナーさんの作ったデザインを元にして、エンジニアがJavaScript, CSSなどのデザインリソースを実装します。 その後
こんにちは、sue445です。 先日社内で使ってるGitLabのリプレイスをしたのでその辺の話をしたいと思います。 リプレイスの内容 今回のGitLabリプレイスでは主に下記を行いました。 サーバ移設に伴いURL以外全部変えた レガシーな環境で運用されていたGitLabを全てDockerコンテナに載せた MySQLからPostgreSQLに移行 以上を1時間弱のメンテでやりきった 構成 ざっくり書くと、SSL終端のフロントサーバのみ同じで、それ以外のバックエンドを全部変えました。 旧 APサーバ Debian Wheezy CPU: Intel Xeon E5-2640v2 * 2 Memory: 40GB Disk: 64G + 512G MySQL兼Redisサーバ Debian Wheezy CPU: Intel Xeon X3430 Memory: 8GB Disk: 256G M
Ansible TowerとGitLabを入れてどういう運用を実現したかったかを簡単な例と一緒にまとめてみようと思います。(自分への備忘録含め) ここに書くこと ここでは Ansible Night in Tokyo 2019.04 で話をした中のLinuxサーバ運用編ついてもう少し詳細に書いてみようと思います。 ここで言う運用のイメージは 定常運用 です。 Excel運用課題の振り返り ファイルの管理が「yyyymmdd」などファイルの末尾で管理されていたりしてどれが最新か分かりにくい 手順書の変更履歴が表で管理されていて文字しか書いていなくて before after が分かりにくい レビューシートが手順書ごとに出来ていく、これも日付管理されたり文字で書いてあるだけなので実際にどう修正したのかが残らない 手順書フォーマットは統一されているが、人によって手順の内容がバラバラ 「このファイ
どのクラウドでも使えるサーバレス「GitLab Serverless」をGitLabが発表。KubernetesとKnativeがベース GitLab ServerlessはKnativeをベースにKubernetes上で稼働するサーバレスプラットフォームです。GitLabがホスティングするのではなく、AWSやGoogle Cloud Platformなどどのクラウドに対してもデプロイし使えることが最大の特徴と言えるでしょう。 GitLabはマルチクラウドに対応したサーバレス管理ツールを提供するTriggerMeshと協力することで、デプロイ後の運用まで一貫してGitLabで管理できるとしています。 現在、AWS LambdaやGoogle Cloud Functions、Azure Functionsなど主要なクラウドは独自のサーバレスプラットフォームを提供しています。しかしそれぞれのク
社内外でちょいちょい聞かれるのでメモ。 前置き GitHubを使ってる場合 ライブラリを作ってる場合 Travis CIを選択する理由 2020/4/21追記 Travis CIを選択しない理由 アプリを作ってる場合 CircleCIとWerckerの共通点 CircleCIとWerckerの機能差異 GitLabを使ってる場合 GitLab CIの優位点 Jenkinsなどを使った方がいい場合 追記:2018/12/8 前置き 100%自分の主観なので偏ってます SaaSかオンプレならSaaS派。(自分でサーバの面倒身たくない) 自分が使ったことがないものは紹介していません 今回紹介してるTravis CI, CircleCI, Wercker, GitLab CI, Jenkinsに関しては仕事や趣味で各3〜4年くらいは使ってるはず GitHubを使ってる場合 ライブラリを作ってる場合
はじめまして、エンジニアリンググループの山口です。9月にjoinし、クラウド型電子カルテ「デジカル」を開発しています(今後「エムスリーデジカル」として本格展開することがプレスリリースで発表されました!)。 今回は、テスト並列化や札束ビンタ以外の方法で、GitLab CIの実行時間を15%短縮した話です。 3行でまとめると GitLab CIのrawログに隠し要素がある 原因の深掘り大事 キャッシュを雑に設定してはいけない 前提: デジカルの開発スタイル デジカルは、 Ruby, Scala, Java, JavaScript と複数の言語を組み合わせてサービスを構成しています。 チームの開発スタイルは以下の通りで、比較的安全に開発が進められるようになっています。 git-flowに近い開発フロー GitLab CIによるビルド、ユニットテスト、静的解析 窓が壊れているのを放置しない (割れ
GitLab.com、200TB超のデータとともにAzureからGCPへ移行完了。三度の計画停止による予行演習を繰り返し、移行手順も公開 ソースコード管理サービスを提供するGitLab.comは、GitHubの競合として見なされています。そのため、今年の6月にマイクロソフトがGitHubを買収するとの報道の際には、大手企業の傘下にない独立したGitサービスの提供元として突如として注目度が上昇していました。 参考:GitLabへのインポートが普段の10倍に急増、GitHubの買収報道で その同じ6月、GitLab.comはこれまで同社のサービスを提供する基盤として利用してきたMicrosoft Azureから、Google Cloud Platformへ移行することを発表します。 I wrote a post about @gitlab's project to migrate our SA
Steven J. Vaughan-Nichols (Special to ZDNET.com) 翻訳校正: 編集部 2018-06-26 15:55 MicrosoftによるGitHub買収発表で、GitHubと競合するGitLabに多くのオープンソース開発者が流れた。そして、そのGitLabが今度はコードリポジトリを「Microsoft Azure」から「Google Cloud Platform」(GCP)に移行する。 GitLabでGoogle Cloud Platformへの移行プロジェクトを主導するAndrew Newdigate氏は移行の目的について、サービスのパフォーマンスと信頼性を改善するためだと述べている。 さらに具体的に言うと、GitLabはKubernetesに将来性を見出していることを移行の理由に挙げている。GitLabは、Kubernetesが「大規模な環境での
GitHubがマイクロソフトに買収されるのではないかと報道されています。Publickeyでは6月2日にBusiness InsiderとCNBCの報道を紹介しました。 マイクロソフトがGitHubの買収交渉、複数メディアが報じる - Publickey 6月4日付けのBloombergの報道ではすでに両社が買収に合意しており、今日にでも発表される予定だとしています。 Microsoft Will Acquire Coding Site GitHub - Bloomberg 追記:正式にマイクロソフトによるGitHubの買収が発表されました。 (2018/6/4 22:50) [速報]GitHub、マイクロソフトによる買収を正式発表 - Publickey 普段の10倍以上のインポートがGitLabへ そうしたなかで、GitHubと同様にGit対応のコードリポジトリサービスを提供しているG
GitLab 10.4では、デプロイ前のDockerイメージに対して静的セキュリティ解析を行うツールや、動的にセキュリティ解析を行うツール、そしてWebブラウザから利用できる統合開発ツールなどが搭載された。 主な新機能として、アプリケーションをDockerコンテナとしてパッケージしたあとで静的セキュリティ解析を行う「Static Application Security Testing (SAST) for Docker Containers」、Webアプリケーションに対して動的なセキュリティテストが可能な「Dynamic Application Security Testing (DAST)」、そしてWebブラウザでコードを編集できるWebIDE機能などが搭載されました。 clairを用いてコンテナの静的解析 GitLabには、コードの静的解析を行う「Code Quality」機能がすで
GitLab、Slackライクなサービス「Gitter」をオープンソースで公開。MacOS対応。Windows版とLinux版も作業中 ソースコード管理サービスを提供するGitLabは、GitHubなどに対応する開発者向けチャットサービス「Gitter」をオープンソースとして公開しました。 公開先は当然ながらGitHubではなくGitLab.orgです。 Gitterは今年3月にGitLabに買収されました。このときには有償プランが廃止され、何人でも無料で利用可能になっています。そしてこのときに同じくGitterをオープンソースにすることも約束されており、今回その約束が果たされたことになります。 Gitterとは、GitHubやTwitterのアカウントを用いて誰でも簡単にチャットルームを開始できるサービスです。Slackに似ていて、GitHubと連携して開発中のソフトウェアに関するコミュ
こんにちは、今年は2017年ですね。tanakaです。 このたび、2009年からコミット履歴のあるプロジェクトのSVNリポジトリをようやくGitに移行しました。 その手順やハマリどころについてまとめておきたいと思います。 移行前と移行後の制作フローとか このSVNリポジトリは、開発用ブランチ trunk とリリース用ブランチ branches/RB の2本が常設してあり、 trunk でリリース可能になったコミットだけをCherry pick で branches/RB にマージする運用をしており、 マージしないコミットが増えると衝突が発生したり、時間経過で差が増えていき辛い感じになってました。 そこでGit(GitLab)に移行することにしました。 移行にあたり、ブランチ戦略としてGitHub Flow を導入しました。 master への直接のプッシュは禁止し、すべてマージリクエストで
主な新機能として、バーンダウンチャート、Canay Deployments、Service Deskなどがあります。 バーンダウンチャート バーンダウンチャートとは、バックログの残量がどれだけかなどを視覚的に分かりやすく表示できるチャートです。 GitLab 9.1ではこのバーンダウンチャートの表示機能が追加されました。これにより開発作業が順調に進み、バックログが計画通りに減っているかどうかや作業のスピードなどがひと目で分かるようになっています。 Canary Deployments GitLabには継続的デリバリの機能のひとつとして、開発したアプリケーションをKubernetesの環境にデプロイする機能があります。GitLab 9.1ではこの機能が拡張され、新しく開発されたアプリケーションをKubernetesによるクラスタ環境の一部にだけデプロイしてようすを見る「Canary Depl
「GitLab 9.0」リリース。組織の階層構造に対応したSubgroups、コンテナへのデプロイとPrometheusで運用監視など GitLabは、無料でオープンソースの「GitLab Community Edition」(以下CE)と有料で機能強化された「GitLab Enterprise Edition」があり、さらにEnterprise Editionには「Enterprise Edition Starter」(以下EES)と、「Enterprise Edition Premium」(以下EEP)があり、それぞれ機能やサポート体制が異なっています。 組織の階層構造に対応するSubgroupsや、Prometheus対応 GitLab 9.0ではさまざまな新機能が追加されましたが、CE/EES/EEPのすべてに共通する大きな機能追加のひとつが「Subgroups」です。これは開発チ
GitLab、Slackライクなサービス「Gitter」を買収。有償プラン廃止で何人でも無料で利用可能に。オープンソース化も約束 GitHub互換のソースコード管理サービスを提供するGitLabは、GitHubなどに対応する開発者向けチャットサービスを提供するGitterを買収すると発表しました。 Gitterとは、GitHubやTwitterのアカウントを用いて誰でも簡単にチャットルームを開始できるサービスです。Slackに似ていて、GitHubと連携して開発中のソフトウェアに関するコミュニケーションを便利に行うことができます。 買収後もGitterは単独のサービスとして継続して提供され、GitHubやTwitterのアカウントによるログインもそのまま続けるとのこと。さらに今後数か月でGitLabとの統合も実現していくとしています。 さらにGitterがオープンソース化されるとのことも示
果たしてGitLab.comで何が起きたのでしょうか? これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時(世界協定時。日本時間2月1日午前8時)、YP氏(Yorick Peterse氏と思われる)はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く