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.
Đố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”.
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
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 đó.
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.
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:
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
Đầ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.
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.
Đâ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.
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.
.jpg)
.jpg)
