はじめに この記事の内容 この記事は上記記事で作成したデータベースに接続するテストの仕組みを運用した際に発生した問題点とそれに対する分析、解決策の案をまとめた記事です。 データベースに接続するテストの詳細な内容は上記記事を参照していただければと思うのですが、作った仕組みの概要としては データベースに接続するJUnitTestをCIで実行するしくみ です。 これによって私が開発しているプロダクトのテストの仕組みの全体像は以下のようになりました。 CIで実行されるJUnitTest（Javaプロセスのみ）の実行基盤 CIで実行されるJUnitTest（データベースにアクセスする）の実行基盤 機能開発時に開発者が作成し協力会社の打鍵者の方に依頼するファンクショナルテスト これは自動E2Eテスト等でカバーできるものも含まれており、そういった仕組みも整備しなければいけないという課題認識があります。

この記事に書いてあること プロになるためのSpring入門のSpringSecurityに関する内容を読んだまとめ SpringSecurityを使った実装例 SpringSecurityとは SpringFrameworkの認証認可を実現するための仕組み。 認証とは アプリケーションを使用するユーザーを特定すること。 認可とは 認証したユーザーが行った操作の可否を制御すること。 認証認可はなぜ必要か 認証認可の実装がされていないと多くのアプリケーションの機能は成り立たない。 例えばSNSであれば投稿された内容は全てのユーザーが見えるようにしつつ、投稿の編集・削除は投稿したユーザーにしかできないようにする、というような制御が必要になる。 SpringSecurityを使った実装 認証とリクエスト単位での認可 概念 認証処理はあらゆるアプリケーションの処理を実行する前に行う必要がある。 Sp

この記事の内容 こんなものを作ったよーという共有 割と簡単にできたのでVSCodeのExtension作成楽しいよーという布教 実装について 詰まりポイントと解消法 パッケージした各ファイルの情報がリリース情報のどこに反映されるのか？ Marketplaceにpublishする時のアクセストークンの権限設定がややこしい Extensionを作成するために必要な環境準備はすでに分かりやすくまとまった記事がたくさんあったのでそちらを紹介するにとどめます。 できたもの Javaクラスを開いた状態で Ctrl + 9 を押すとテスティングペアのJavaクラスを開く（なければ作る）という超単純なExtensionです。 EclipseのQuick Junit Pluginのショートカットキーの一つとほぼ同じ動きをします。 当方Eclipseずぶずぶテスト大好きおじさんのため、このショートカットキーが

はじめに かれこれ１年以上前のことになりますが、今の開発組織でデータベースに接続するJunitを使ったIntegrationTest1 を開発者のPCとCIで実行できる仕組みを作りました。 トライしたきっかけと想い 仕組みの設計・導入をする時に気を付けたこと 具体的な実現方法 トライしてみて感じたこと を記載します。 トライしたきっかけと想い 私が保守開発を担当しているプロダクトは20年近く運用されているWebアプリケーションです。(サーバーサイドはJava) 単体テストの仕組みと文化が無いまま長期間運用されており、大半のコードがレガシーコードという状態でした。 一部テストが書かれている箇所もありましたが、CIでの実行の仕組みはなく腐ってしまっているものも多い状態でした。 そこに @autotaker1984 さんがCIでの単体テスト実行の仕組みを作ってくれて、単体テストを書くべきというマ

私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは

昨年6月頃から継続してチームメンバーを増員してもらいながら チームとしてモウダメダーという状況から少しずつ製品を改善していける体制を整えてきました。 その際の取り組みとして上手くいったこと、上手くいかなかったこととどういう工夫をしたのかを記します。 製品の状況 人事給与システムのデータ投入・照会など従業員が利用する機能群をまとめた製品 （例） 住所変更、通勤経路の変更などの申請 給与明細、社員情報、組織図の照会 など 運用期間 約20年 ユーザー数 約1000社 チームが担当する機能の状況 製品内での人の配置に関する情報の人事給与本体からの連携とその情報を利用した条件設定機能の保守 ほぼ全ユーザーが利用しておりある程度枯れているが、人事給与本体からデータを連携してくる部分はトラブルが緊急対応に発展しやすく、条件設定は複雑な設定も組めむことができ運用サポートする負荷は高い 細かい項目の対応漏

エンジニアが学ぶ・働く・成長する文化を共に創ろう 日々の限られた時間の中でも知識や情報をアップデートしてワクワクしたい。 自分らしくいられる組織の中で、自由にイキイキと楽しく働きたい。 そして、自分の成長が世の中の豊かさにつながっていく。 そんなエンジニア文化を推進したいForkwellによる年に1度の文化祭です オンライン・オフラインの同時開催となっておりオフライン会場では 2トラックでのSession（かなり豪華な面々）と来場者どうしがカフェや懇親会で交流することができるイベントでした。 参加に至った経緯 弊社では今年１月に数年ぶりにオフラインでのKickOffイベントが開催されました。 我々のチームはフルリモートで運営しており、 勤務地も東京と大阪のメンバーが入り混じっています。 そのため2年近く同じチームで働いているのに、 オフラインで顔を合わせたことがないメンバーがいたりしました