Gặp gỡ team Magestore tại series 'Chân chất kể tất - Webinar #8: "Cách làm Content Marketing bằng sự thấu hiểu B2B Buyer Journey"
Đăng ký tham gia!

Webinar Thất bại và thành công của Magestore khi triển khai DevOps

Webinar số 5 nằm trong series Chân chất kể tất là nơi mà chúng tôi chia sẻ câu chuyện thất bại và bài học kinh nghiệm rút ra được của đội ngũ Software Engineer Magestore khi triển khai DevOps. 
Webinar này với sự tham gia của 2 speaker “cây nhà lá vườn” Walter Đỗ và Oliver Hoàng mang tới cho khán giả góc nhìn vô cùng chân thực về một thời kỳ nhiều đau đớn khi triển khai DevOps tại Magestore. Cùng xem lại các nội dung chính ngay dưới đây. 
Nội dung chính


Lịch sử DevOps và bối cảnh Magestore khi bắt đầu áp dụng DevOps

Theo wikipedia, DevOps là một bộ các practices cho phép kết hợp quy trình phát triển phần mềm (team developer) và team vận hành (operations). DevOps cho phép rút ngắn vòng đời phát triển phần mềm và liên tục đưa ra bản cập nhật tới khách hàng với chất lượng tốt hơn. 

Có một khái niệm nữa do 3 nhà computer science là Len Bass, Ingo Weber và Liming Zhu  định nghĩa. Theo đó, DevOps là bộ các practices cho phép giảm thời gian giữa việc đưa ra 1 thay đổi với hệ thống và việc mang thay đổi đó lên môi trường production. 

Khi chúng ta giảm được thời gian, tức là công ty có thể cắt giảm chi phí và nâng cao hiệu suất của công ty. 

Bên cạnh đó có 2 trường phái, 1 bên coi DevOps là 1 vị trí trong team. Một bên coi DevOps là 1 dạng văn hóa. Nhưng nhìn rộng ra thì DevOps có thể coi là 1 văn hóa. 

Tại sao vậy? 

Agile và DevOps thực tế luôn song hành với nhau. Các tiêu chuẩn của DevOps đều bắt nguồn từ Agile. Nhờ các thực hành của DevOps, Agile cũng trở nên thực tế hơn, đi vào đời sống doanh nghiệp hơn. 2 phạm trù này bổ sung và gắn kết mật thiết với nhau. 

Cụ thể, Agile và DevOps có sự tương đồng như thế nào mà chúng lại có thể đi với nhau?

Bạn có thể thấy Agile sinh ra để đưa khách hàng và những nhà phát triển sản phẩm gần nhau hơn. Còn DevOps sinh ra để đưa khoảng cách giữa nhà phát triển và nhà vận hành gần nhau hơn. Vì thế, có thể nói Agile và DevOps luôn bổ trợ cho nhau. Tất cả đều giúp cho mọi người (khách hàng, nhà phát triển, nhà vận hành) gần nhau hơn. Chính những người vận hành là cầu nối giữa khách hàng và nhà phát triển. Nếu không nhìn nhận như vậy, chúng ta sẽ dễ lâm vào tình trạng developer cứ việc phát triển một đằng, còn bên vận hành cũng lại triển khai cho khách hàng một đằng khác dẫn tới bị vênh nhau. 


Khi tất cả các bên cùng cộng tác và hỗ trợ lẫn nhau để đưa sản phẩm tới tay khách hàng thì tạo nên một văn hóa đầy tính cộng tác, một văn hóa mà ai cũng có thể đóng góp vào kết quả cuối cùng. 

Bối cảnh của Magestore thời kỳ đầu

Đối với các công ty làm sản phẩm SaaS thì quá trình CI/CD diễn ra nhanh, thậm chí có thể trong ngày là đã đưa được cập nhật tới khách hàng. Tuy nhiên đối với các công ty làm sản phẩm on-premise như Magestore thì có cách nào để làm được điều đó không?

Trước đây, Magestore vốn xuất phát là một công ty phát triển các extensions cho nhà bán lẻ trên nền tảng Magento. Đây là các sản phẩm dạng on-premise, khách hàng sẽ lên marketplace để tải về. 

Ở thời gian đầu, khi Magestore mới phát triển các extension, thì sản xuất rất nhiều và nhanh để đưa ra thị trường. Khách hàng cũng nhỏ, dễ tính nên hồi đó các anh em dev khá chủ quan trong quá trình phát triển. 

Trong giai đoạn này, hầu hết đội phát triển và triển khai đều test bằng tay. Dẫn đến bug sản phẩm mà khách hàng report về phải đợi rất lâu mới được fix. Đội triển khai thậm chí đã lên live site của khách để hot fix, không cần test kỹ lưỡng. 

Tiếp đó, nhìn ra bên ngoài, thấy tình hình phát triển extension không mấy khả quan trên thị trường, ban lãnh đạo công ty đưa ra quyết định chuyển mình, muốn công ty giải quyết những bài toán lớn hơn cho khách hàng. Tuy nhiên lúc đó đội ngũ Magestore lại suy nghĩ khá đơn giản. Gộp chung các extension lại thành 1 bộ giải pháp cho khách hàng. 

Mấu chốt là việc kết hợp các extension này lại không có đánh phiên bản (version), không commit lên git. Dẫn đến sản phẩm cực nhiều bug vì mỗi người developer lại phát triển trên một môi trường khác nhau. Rồi việc test lại càng trở nên khó khăn, tính ổn định của sản phẩm không cao. Lúc đó thậm chí công ty còn sinh ra hẳn 1 team chỉ để đi fix bug cho khách, mà quá nửa số bug này không thể cập nhật vào bộ sản phẩm core.

Trong giai đoạn đó, đội ngũ Magestore đã gặp rất nhiều áp lực và rối ren: áp lực về doanh số, áp lực về việc tìm kiếm khách hàng mới. Doanh số công ty gần như chạm đáy. Rồi các team phát triển và triển khai tranh cãi, đổ lỗi cho nhau. Rồi nhân sự dần ra đi, không để lại những tri thức gì đáng kể. Đúng là một thời kỳ vô cùng đau đớn đối với toàn Magestore.

Trong lúc khó khăn ấy,  anh Walter, lúc đó từ 1 team khác đã mạnh dạn tham gia hỗ trợ. Đứng ở  một góc nhìn hoàn toàn mới, mang luồng gió mới và những khái niệm mới vào đội ngũ triển khai, bắt đầu những bước đi đầu tiên của chặng đường DevOps với practice “Automation”. 

Bài học kinh nghiệm khi lần đầu đưa DevOps vào đội ngũ và gặp thất bại

Khi bắt đầu đưa vào áp dụng Automation test ở đội ngũ, anh Walter nhanh chóng nhận những kết quả không như mong muốn

  • Đưa Automation Test vào tự làm, mà chẳng cần để ý đến ai, không thực sự áp dụng vào chu trình phát triển phần mềm. Các team khác đang có quy trình riêng, và không hiểu được điều mà anh Walter muốn làm.
  • Nghiên cứu coding standards, đưa ra tiêu chuẩn giúp mọi người commit code cho tốt hơn. Nhưng chỉ là một chiều, và không thuyết phục được cả đội ngũ triển khai áp dụng vào thực tế.
  • Nhận ra document không được cập nhật thường xuyên, không đánh số phiên bản. Không ai quan tâm đóng góp viết document.
  • Chuyển server lên Cloud, nhưng vẫn triển khai bằng tay. Quản lý các tài khoản server ảo không cặn kẽ, dẫn đến chi phí đội lên. 

Trong giai đoạn này, nhận ra những điểm yếu trong hệ thống tổ chức đội ngũ, các lãnh đạo công ty đã nhận ra mấu chốt nằm ở khâu quản trị và cơ cấu tổ chức nhiều hơn. Vậy là ban lãn đạo Magestore bắt đầu đi học về Agile, mang văn hóa Agile, các quy trình framework Scrum về áp dụng cho đội ngũ anh em làm IT. 

Dần dần khi có mindset Agile - mindset cộng tác và liên tục học hỏi, chuyển giao & cải tiến trong đội ngũ, team biết cách làm việc có khoa học hơn. Team tiếp tục  học từ cuốn sách The Phoenix Project và  áp dụng thêm branch strategy,  bước đầu sử dụng được Jenkins flow một cách đơn giản để check code standard và nhìn thấy hiệu quả. Tiếp đến và đánh version các sản phẩm để ai cũng có thể nhận diện được các phiên bản khác nhau. 

Nhưng team vẫn nhìn ra những hạn chế ở thời điểm đó. 

  • Team triển khai áp dụng Gitlab runner mà không theo branch strategy  nhưng không có sự đồng thuận giữa các thành viên
  • Không thể dò lại các thông tin về sản phẩm vì team đã làm mọi thứ bằng tay, không hề ghi lại trong document
  • Định nghĩa commit standard nhưng hầu hết đều không tuân theo. 

Vì thế, một lần nữa, các team triển khai lại phải ngồi với nhau cùng thống nhất, liên kết lại định nghĩa được các quy trình triển khai cho khách hàng. Thống nhất rằng mọi người cần cùng cố gắng học hỏi và trau dồi kiến thức để reboot lại quy trình. 

Quá trình đưa DevOps vào Magestore vẫn đang diễn ra

Triển khai DevOps lại từ đầu

Khi phát hiện quy trình triển khai cho khách hàng lại gây ra nhiều vấn đề khi bàn giao sản phẩm đến tay khách hàng. 

Nhận ra điều này, team đã có những hành động như sau: 

1. Chuẩn hóa quy trình 

Trước đây team chưa chuẩn hóa quy trình dẫn đến mỗi người một kiểu, không thống nhất. 

Ví dụ khi đóng package chuyển cho khách hàng thì người này làm khác, người kia làm khác. Lỗi phát sinh ở khâu này thường xảy ra. 

Việc chuẩn hóa quy trình này có thể giúp bắt đầu tìm giải pháp automation cho quy trình đó. 

Cụ thể quá trình chuẩn hóa quy trình này bao gồm

Chuẩn hóa quy trình phát triển:

  • Áp dụng Gitflow: Ngày trước team có học được concept Git flow trên thế giới và áp dụng lại theo kiểu nửa vời, chỉ dùng để lưu trữ code. Nhưng giờ team đã chuẩn hóa lại và áp dụng đánh version, trong quá trình phát triển giải pháp. 
  • Áp dụng coding standard
  • Chuẩn hóa môi trường development và test: Khi bắt đầu dự án, team lấy thông tin về môi trường của khách để clone về local và nhân bản ra. Khi mình clone được về thì mình có thể phát hiện được các lỗi sớm và khi go live cho khách hàng sẽ giảm được lỗi.
  • Áp dụng CI (Continuous Integration): Liên tục tích hợp code giữa các developer. Team áp dụng chia task nhỏ hơn nửa ngày. Điều này giúp cho các developer release code rất nhanh. 

Chuẩn hóa quy trình release:

  • Đánh version: Đánh version cho những phần custom code để dễ dàng quản lý version và fix bug
  • Quy trình build và đóng package: Thống nhất cách đóng gói package chuyển tới tay khách hàng. 
  • Thực hiện Release hàng tuần: Khi đã chia nhỏ được các công việc nhỏ làm theo ngày, thì mình hoàn toàn có khả năng phát hành hàng tuần các US cho khách hàng. 

Chuẩn hóa quy trình deployment

  • Chuyển giao package hàng tuần: Khi đã release hàng tuần rồi thì khách có thể nhận package theo tuần. Nếu khách chưa muốn nhận thì package vẫn ở đó, sẵn sàng chờ khách hàng tiếp nhận và tải về. 
  • Acceptance Demo: Tổ chức các buổi nghiệm thu và demo sản phẩm để khách hàng xác nhận.
  • Chuẩn hóa các chỉ dẫn/hướng dẫn dành cho khách hàng: Thống nhất các cách thức chỉ dẫn cho khách hàng để họ làm việc với team.

2. Document các tri thức:

Vì sao cần lưu trữ, ghi lại các tri thức?

  •  Lưu trữ kiến thức để tìm lại, và không mất thời gian tra cứu. 
  • Document còn dùng để training cho người mới. 
  • Khi document lại, team có thể dùng để review lại cùng nhau. 

Làm thế nào để lưu trữ document tri thức?

Đầu tiên, Magestore đã xây dựng một hệ thống lưu trữ tri thức của toàn công ty ở đó ai cũng có thể viết bài, chia sẻ, đóng góp kiến thức mang tên stories.magestore.com. Sau đó tiếp tục phát triển hệ thống handbook.magestore.com - nơi lưu trữ quy trình chính thống của công ty. 

Hệ thống chia sẻ tri thức toàn dân https://stories.magestore.com


Hệ thống lưu trữ public quy trình official tại công ty https://handbook.magestore.com/

Cần nhấn mạnh là công ty cho phép ai trong công ty cũng có quyền đóng góp vào hệ thống tri thức này.
Tiếp đó, công ty áp dụng quy trình vòng lặp DevOps, từ việc xây dựng, rồi review, release, deploy, monitor các document này. 

Giới thiệu một vài cách thức Tự động hóa tại Magestore

Đây là hình ảnh mô tả các công nghệ mà Magestore đang sử dụng để phát triển và vận hành. 


Monitor các version của sản phẩm trên Odoo


Các bot gửi notification tự động thông báo khi các phiên bản sản phẩm được cập nhật

Kết luận

Với các trải nghiệm qua nhiều lần thất bại, cuối webinar, 2 diễn giả đã đúc rút được được cacác bài học quý giá cho bản thân và đội nhóm của mình, để chia sẻ với người tham gia. 


Một công ty muốn phát triển DevOps từ thời điểm nào? 

Áp dụng từ những ngày đầu tiên, không nên để lâu. Vì càng nhiều phòng ban, càng mất thời gian để thống nhất. 

Làm thế nào để áp dụng DevOps?

Phải đi từ business mindset, từ cơ cấu doanh nghiệp, quy trình của doanh nghiệp. Chứ không phải đi từ công cụ, tự động hóa. Khi có sự ổn định trong nội bộ thì mỗi người sẽ đưa ra được những cải tiến liên tục cho quy trình, cho sản phẩm của cả công ty.

Ai có thể áp dụng DevOps?

Tất nhiên vẫn cần có vị trí DevOps Engineer hiểu biết về công nghệ, hoàn thiện các quy trình công ty. Thì tất cả mọi nhân viên trong công ty đều có thể đóng vai trò tham gia vào quá trình DevOps. Vì họ có thể nghĩ ra các cải tiến cho quy trình, giúp giảm thiểu thời gian giữa việc phát triển và đưa sản phẩm tới tay khách hàng. 

DevOps không còn chỉ là một vị trí, mà còn là 1 văn hóa mà ở đó ai cũng liên tục cải tiến, liên tục chuyển giao giá trị, nhanh hơn tới khách hàng. 

Bạn muốn xem cụ thể chi tiết hơn, hãy đi tới video ghi hình buổi webinar đã được chia sẻ public tại đây


Hiện giờ hệ thống, quy trình của Magestore vẫn đang hàng ngày được cải tiến và quản lý nhờ vào áp dụng văn hóa Agile, và các thực hành của DevOps. Và nếu bạn cảm thấy yêu thích văn hóa và phương thức làm việc của Magestore, hoặc đặc biệt yêu thích làm DevOps Engineer thì chúng mình vẫn luôn chào đón các bạn ứng tuyển tại đây.

Về chung một nhà với Magestore

More Articles