blog試したこと・調べたこと・感じたことを発信するITエンジニアの日記です。仕事とは直接関係ないけど興味あることを模索していきます。この広告は、90日以上更新していないブログに表示しています。著)書評すでにベストセラーなので読んだ方も多いかも知れません。読んでもらいたいと思いました。私も一応エンジニアなので私が感じたことを書くことで少しでもエンジニアの方が興味を持ってくれればなぁと思い、ブログに書くことにしました。パイプラインを構築することをやってみたいと思います。Testのやり方とかは過去記事を参考にしてください。こんな感じの手順になります。Testの作成テストコードのビルド定義アプリケーション/テストのリリース定義リリース実行(テスト実行)VSTSのプロジェクトの作成や、今回は使用しているAzureの設定などの細かいところは割愛してます。2017に参加しました。目的はもちろん最新技術動向の把握にあるのですが、それと合わせてDevOpsとその言葉の裏にある「ソフトウェア開発の生産性向上」が裏テーマです。今回は、私が聞いて感じたことと日々感じていることと合わせて書いていこうと思いました。所属組織は関係なく個人的な意見ですのであしからず。私が参加したDevOps系(生産性向上)のセッションは下記です。時間」(#DO08より)です。2択しかないわけです。昨今、世の中の働き方改革という名のもとで、残業禁止となり時間を増やすことが難しい現状になっています。同じ総量で早く帰らないといけない場合には、生産性を上げなければいけないわけです。言われるとその通りと納得せざるを得ないです。「アメリカと日本の生産性を比較すると100:62」(#SP05より)だそうです。そりゃ日本人が定時で帰れないわけです。日本人は生産性が低いのか。日本は重要なこと以外に時間をかけすぎている、米国は本当に自分が付加価値を出せること以外にのみ集中するからそもそもの物量が違う、日本は5つに対して優先度を決めて4つぐらいまでやろうとする、米国では最優先の1つのみやる、だから生産性が低いように見える、重要な1に8割の価値があるから尚更そう見える、個人のパフォーマンスが一概に低いからだけではない、牛尾さんのセッションではそうおっしゃってました。現場では作業に追われているのが日常で、無駄な作業が多いように私も感じています。生産性向上の前に総量の削減が必要。概ねこの意見には賛同です。1点、一見無駄なことなのかもしれないけれど、そこをやる日本の良さもあるのではないかと思う。勤勉に几帳面にやっていくその通り良さは必ずあるはず。作業量は減らすけれどその点忘れないようにしていきたいな。個人のパフォーマンス個人のパフォーマンスについては、米国のレベルを肌で感じたことがないので正直わからないのですが、現場を見ていてパフォーマンスが良いとは感じない。すごい方とも沢山出会ってきましたが、全体的なレベルを見ると心もとない感じがします。現場でアーキテクトとしてコードの品質チェックしていますが、どちらかというと不安になるレベルの方が多いです。私個人としてはプログラマは高い専門性が求められる職業であると思っています。Rochelleさんもプログラマが他の業務にジョブローテーションされるのはおかしいと言い切ってました。私はこの点について、大学での教育(専門的な教育)と企業の採用(誰でもSEになれる風潮)に疑問を持ってます。この点について個人として出来ることは限られるので、現場にいるメンバでなんとかするしかないのが現状で、チーム全体の底上げをどうするかを現場レベルから考えないといけないです。赤間さんのセッションでの、「開発技術の進化があれば、その恩恵により開発生産性をは改善されるはず」というのは私が日々思っていることを本当に代弁してくれたような言葉でした。SI業界にまだ10年ほどしか関わってませんが、開発のやり方は全く変わってません。これは、SIerとして反省すべき点だと思いました。個人としては色々なツールの導入や工夫をしてますが、組織全体として変わってきたかと言われればほぼ変わっていない。それに対して何も疑問に感じていないというのはいかがなものか。「日本のSI商習慣(多重請負構造)が問題」「SIerのプロパーが最新技術を知らない」(#DO08より)というのは実に的を得ている。アーキテクトは現場を改善していく責務があると再認識しました。最新技術の恩恵をどう受けるのかソフトウェア開発のプラクティスとしてDevOpsが叫ばれていますが、日本にそのまま当てはまるとは個人的には思っていない。Rochelleさん&牛尾さんは、DevOpsを適用するためには、欧米文化をインストールしていけば良いとはというアプローチ(8つの習慣)で、出来るところからチームで初めていくことを勧められていました。赤間さんは、DevOpsを支える色々な要素を取捨しながら取り込んでいけば良いとおっしゃっていました。現場レベルから改善を繰り返していき少しずつ生産性を高める必要性があります。その際に様々な開発技術の恩恵をいち早く受けるためには、「自動化しなくて済むようにする」つまり「巨人の肩に乗る」(#DO09より)という考え方も大切だと思いました。一生懸命仕組みを考えるというより、今の時代は「レールに素直に乗せて上げること」がアーキテクトの役割の1つなのかもしれないなと感じました。牛尾さんのスライドです。docs.comさいごにいろいろ書きました(あまりまとまっていないかもしれませんが・・・)が、DevOpsというのは手段の1つであり、導入する目的を考えないといけないことを再認識しました。今回de:codeに参加して、ソフトウェア開発の生産性向上をしたいと改めて思いましたし、出来ることから1つずつやっていき、理想形に近づけていくという地道なアプローチしかないこともわかりました。使えるものは使っていく、VSTSやAzureなどは素晴らしいのでバンバン使っていきたいと思いました。Studioとの連携も強力です。Azureを用いれば、簡単に“CI/CD”を行うことも可能です。Agentを設定する方法を記載します。Agentの設定をしました。ビルドサーバを独自のものを用意したいという場合には参考になると思います。Proxy組織に所属する限りProxyを経由しないとインターネットに出れないというのは当たり前ですね。パブリッククラウドがかなり発展してきている中で、少し不自由な時があるのが実情だと思います。セキュリティの関係で仕方ないと言えば仕方ないのですが、どうにかしたいのも事実です。Machineにリモートデスクトップ(RDP)する方法はないものかと気になったので試してみました。HTTPで対象のサーバとSSHを確立して、SSHポート転送でRDPをフォワードするという方法でなんとかつなぐことが出来ました。いやぁ、なんのこっちゃって感じですよね。絶対に忘れそうなので自分自身への備忘も兼ね方法をまとめておきます。同じことで悩んでる人の少しでも参考になればと思います。2017ではGraph形式のデータが扱えるようになりました。Graphデータがどのようなものかは、前回の投稿でやってみましたが、データ件数がそれほど多くなかったので、少し多めのデータ(とりあえず100万件)でどうなるのか試してみたいと思います。Serverに接続できるようにセットアップする方法を試してみたいと思います。Machineに構築した場合、ちゃんとパッケージインストールされていてやる必要がなかったみたいです。気が付くの遅すぎ...でも、方法はわかったので内容は残しておきます。外部からつながっているので、ローカルから接続できるようにする必要性はあまり感じないかもしれないですが、ネットワークを介さずにいろいろやりたいパターンは出てくるはず(例えば、性能測定とか、大量データの挿入とか)なので必要に応じて各環境で実施しておくとよいと思います。何度も言いますが、Azureで構築した場合、親切にパッケージインストールされているはずなので、PATH通すぐらいしかやらなくてOKです。LinuxにアクセスTweet広告を非表示にするもっと読むコメントを書く次のページプロフィールid:ninna2SE歴10年ほどインフラからアプリまで幅広くやっています。情報発信していければと思っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。