私がこの会社に入るまで、そこまで技術的ではありませんでした

全てはふとした思いつきから始まりました!!!

私は自分の仕事にかなり満足していました。仕事は割と単純明快でした。前職であるJFrogやShippableで、非技術者がDevOpsの分野でどう動き、どんな影響を与えられるかを世界に示す機会を与えてくれて、本当に感謝しています。私の仕事のほとんどは、様々なクラウドネイティブ技術のリサーチや、それについての記事を書いたり、開発者にブランドを宣伝したりしていました。執筆やストーリーテリングが好きだったので、LinkedInで技術関連の話をシェアして、素晴らしい反応を得ることができました。結果として、私のネットワークを通じて、32,000人のプロフェッショナルなDevOpsコミュニティを築き上げました。

それをしていて楽しかったのですが、どこかで自分を制限していると感じていました。もっとできるはずだと。私は同じ仕事を6年間続けていましたから。30代に入って、「もう少し真剣になる時が来たのかな」と思う気持ち、わかりますよね?そう、その気持ちがして、居心地の良い場所から抜け出したいと思いました。新しい挑戦をし、もう一度自分を試したかったんです :)

そんなある日、頭にひらめきがありました。自分の殻を破るべきだと。そう、全てはひらめきから始まります。そして、その瞬間に必要な要素がすべて揃い、決断するための助けとなりました。

(画像: 引用)

難しかった?めちゃくちゃ難しかったです!快適なゾーンから抜け出すという考えだけでも...シーッ!!!!でも、やってみる価値はあると決めました。次に何が起こったか?読み進めてください。

宇宙が応えた

ヨガの先生が言っていました。良い意図と純粋な心があれば、何かを望んで本当にそれを起こしたいと思えば、宇宙は耳を傾けて応えてくれます。
私の場合?宇宙はかなり早く応えてくれました。ハハハ :)

皆さんご存じの通り、私はLinkedInで技術関連の話を多くシェアしており、毎日たくさんのメッセージを受け取っています。そんなある日、一人のテックリーダーが私のプロフィールを見ていました。彼は私が転職を考えているかどうか尋ねてきました。少し懐疑的でしたが、快適ゾーンから出るべきだと決心しました。

自分自身に挑戦する時が来ました。ここで助けとなる全ての要素が見えてきました。私たちは(私とそのテックリーダーは)何回かZoomで会い、期待について話し合いました。彼らは私のプロフィールを気に入り、いくつかの面接を経て、双方から「はい」という返事がありました。ついに私のビジョンがはっきりと見え始めました。

でも、実際に私を動かしたのは何だったのか?

チームは小さいけれどパワフルで、優れたリーダーシップを持ち、会社はロケットのように成長しています。いいえ、冗談ではありません。この会社は長い間私のレーダー上にあり、すでに彼らのブログをフォローしていたのです。

私はそこで止まりませんでした。製品、将来の計画、そして人々—全てがポジティブでした。この会社が特に興味深かったのは、非常に少ないマーケティング努力で非常に大きく成長していたことです。本物の製品が実際の問題を解決し、宣伝を必要としない魔法を私は感じることができました。

また、この会社は働きがいのある最高の場所の一つとして認識されています。Glassdoorの評価は印象的で、CEOのJyoti Bansalは、彼の成功したテクノロジー起業家としての旅でファンベースを持っています。

ただ一つのポイントではなく、複数の重要なポイントがこの役割を引き受けるためのこの決断を下すことになりました。私はこの流れに乗ることを決意しました—さあ、中に入ってジェットコースターのような体験を楽しみましょう。そしてついに、私はこの会社に参加しました。

何か大きなことの始まりです!

(画像: Harnessロゴ)

私はHarnessにデベロッパーアドボケイトとして参加しました。基本的に私の仕事は、最適なDevOpsの実践、ツール、ガイドなどを提案することで、開発者がDevOpsの旅をサポートすることです。これをするのが大好きです。なぜなら、それは私が既にLinkedInの投稿や記事を通じて行っていたようなものだからです。

内緒の話ですが、実は私は内向的な性格なんです。でも、マーケティングのような役割でいつもいたので、人々と話すこと、プレゼンをすることには慣れていました。けれども、思い返すと、私はいつもスピーカーや教育者になりたいと思っていました。コミュニティを築き上げながら、知識を共有し、人々と交流しながら、エンジニアリングの話をシェアするのが大好きです。

(画像: IIMBで講演している私)

最初の日、全てがスムーズに進みました。上司が歓迎してくれ、2〜3日後、彼は私にHarnessのCI/CDを実際にどのように機能するかを学び、デモを行うように言いました。えっ。何?デモ?私?何てことでしょう!それは私の恐れが話をしているんです。でも、口を閉ざし、真剣に取り組むことに決めました。それが私の最初の挑戦でした。

本当にこれが正しいと感じました。これは私がやるべきだと。なので、最初のタスクはドローンCIを一から学ぶことでした。なぜドローンCIかというと、Harnessは2020年にドローンを買収し、今ではハーネスの家族の一部になっているからです。そして、私にとって、連続インテグレーションから始めるのが適切な流れのように思えたのです。

手を動かしながらのCI(連続インテグレーション)への道

理論的にはCIが何なのか、なぜ企業がそれを使用しているのかは知っていましたが、実際にどのように実行されているのかは知りませんでした。でも、自分は準備ができていると感じました。GitHubアカウントにログインし、いじり回し始めました。Git push、Git pull、Git cloneなど、いくつかの基本的なことを試すためにリポジトリを作成しました。次に、Azureにサインアップして仮想マシンを作成しました。仮想マシンにsshでログインする方法を学び、Dockerをインストールし、Docker Hubアカウントにログインしました。

たった一週間で、Drone CIサーバーをローカルにセットアップし、基礎的なCIパイプラインの構築を始めました。なぜ連続インテグレーションがとても強力であるかを私は始めて理解しました。今回は、理論だけではなく、企業がどのように行い、何のためにそれが必要なのかも見ることができました。

では、連続インテグレーションとは正確には何でしょうか?

(画像: DevOpsエボリューション)

小さな話をしましょう…
ソフトウェア開発の手法は長い道のりを経てきました。全ては伝統的なウォーターフォールモデルから始まり、要件を収集する人がいて、製品を作る人がいました。テストチームは何が起きているのか知りませんでした。チームはサイロで働き、結果は最良ではありませんでした。

その後、アジャイルやその他のリーンな手法が登場し、より意味のある方法を提供しました。ソフトウェア開発が進化するにつれて、Google、Netflix、Amazonのような企業はクラウドでスケーラブルなソフトウェアの構築を始めました。クラウドコンピューティングは、企業や開発者が新しい方法でビルドする新たな希望をもたらしました。例えば、Flickrは一日に何度もコードを本番環境にデプロイするようになり、そのような例が他の企業を刺激し、開発のスピードアップを図りました。

しかし、いくつかの企業がそのコードを解読しても、開発と運用がどのように一緒に働くのかはまだ混乱していました。通常、それらはボトルネックを形成し、それらのパーティー双方を説得するのは困難でした。これら2つの部門の協力は欠けていました。開発はコードを書き、機能を構築していました。運用はウェブサイトが常に利用可能であることを確認し、質問に答えるなど、何も問題が起きないように物事を進めようとしていました。

全体の流れが壊れていたように感じられ、それがDevOpsという概念が、文化的なジレンマをシフトするためにゲームに参入したときでした。基本的に、DevOpsは開発と運用の間にあるコラボレーションギャップを埋め、これら2つの部門を中心に全てを統合することを目的としていました。

DevOpsを支持する際には、開発から本番環境への機能の移行を迅速に実行するために、連続インテグレーション、連続デリバリー、連続デプロイメントなどの概念がDevOps現象の一部として導入されました。

連続インテグレーションは、ソフトウェア配信を自動化するへの最初のステップです。その名の通り、異なる開発者の作業を統合することを含んでおり、開発者は自分のコードを非常に頻繁に変更し、メインブランチにマージすることで、コードコミットが発生するたびに自動ビルドをトリガーし、指定されたテストでコードが機能することを確認します。これにより、開発パイプラインの早い段階でバグやエラーを発見し、それらが本番環境に入るのを防ぐのに役立ちます。

実用的なCIシナリオ

ある企業をとってみてください。彼らは開発者がコードを書き、それを保存し、製品が計画通りに適切に構築されるように協力するため、ソースコントロール管理ツール(はい、GitHubのことです)を使用します。

開発チームが大きくなるにつれて、日々のコミット数が増加し、バグを見つけたり、ソフトウェア品質をチェックしたり、テストすることが難しくなります。これに対処するため、企業は連続インテグレーションに向かいます—コードマージが行われると、自動的にCIツールをトリガーし、バグや他の問題を見つけるためにコードに対してテストを実行します。

では、実際にどのように機能するのか見てみましょう。

では、ドロー

こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/pavanbelagatti/i-wasnt-that-technical-until-i-joined-this-company-3l2j