Don’t wanna get your wife angry just because of let her wait so long for a dinner? This program is for you. It’s a guide to build the simple application that automatically sends SMS to your wife at a specific time if you need to stay longer at the office.

Get Twilio account

Register an account at: https://www.twilio.com, the service lets you send the SMS via REST API. During trial period, you could get 10$ – enough free messages; then you get charged with low fare later (~0.01 – 0.05$ for each SMS).

Setup Twilio

  1. Buy a number at: https://www.twilio.com/console/phone-numbers/incoming. It costs 1$, Twilio uses this number to send SMS. Call it SENDER.
  2. Verify your wife’s phone number (with country code like +84 988 999 888) at: https://www.twilio.com/console/phone-numbers/verified (to make sure you don’t spam anyone). Call it RECEIVER.
  3. Create API key at: https://www.twilio.com/console/dev-tools/api-keys. You can get API key and secret key here. Call them KSID and KSECRET.
  4. Go to https://www.twilio.com/console and get your account SID. Call it ASID. 

Now replace this command with your information above, replace + in the phone number with %2B.

Then run.

Got it? We are almost done.

Setup a cronjob

You can send SMS to your wife by only 1 command; now get it automated.

1. Create a file sweet_sms_to_darling.sh, put the command above.

2. Get it executable, and run at 18:30 every day.

Add this line, correct your file path, 18, 30 is the hour and minute triggers this bash script.

3. Save this file and add to cronjob. That’s all.

OK, now when your computer is up on 18:30, it automatically send the SMS to your wife.

Don’t worry about she get angry. Now work. 

Please don’t put this job on server – it’s always up 😉

It’s general idea of building the application, you could do it in others platform like Windows with BAT file and scheduled task. Another simpler and specific version for Mac is coming soon 😉

1,366 total views, 2 views today

Following the topic in my short post eXtreme Programming is Dead, I had a talk at the monthly meetup of Agile Vietnam, Feb 2017, to explain more about my opinion.

Half of time, I focused on describing what exact eXtreme Programming (XP) is. Today most of development teams are applying some XP practices but they just do it with forgetting what are behind the scene: values and principles. It’s time to recall to how to do it right.

Then I explain more about my idea, why XP is dead. It’s dead in some ways: teams just follow the practices without knowledge of values and principles, the practices is more and more becoming standards of software development instead of extreme, original XP makes the confusion of applying it at enterprise.

You can find the slide here – it just is the outline, I will try to explain more in longer post later.

842 total views, 1 views today

Tại sao ở Việt Nam, những tư tưởng và thực hành XP không được coi trọng? Theo tôi quan sát, có ba lý do chính.

Một là, ngành CNTT của Việt Nam chủ yếu vẫn đang tiếp cận theo hướng top-down; những vấn đề về công nghệ, phương pháp luận, thực hành vẫn chủ yếu được định hình bởi các quản lý cấp cao, cấp trung. Và XP thường không bao giờ nằm trong danh sách lựa chọn của những nhà quản lý dự án hay quản lý tổ chức thuần tuý, bởi XP không phải là phương pháp luận về “quản lý”.

Hai là, tên. eXtreme Programming chết bởi cái tên. Kent Beck có lẽ nên chọn một cái tên khác, có thể là vô nghĩa thì tốt hơn. XP cho thấy sự coi trọng hoá programming một cách cực đoan. Và thực sự, điều đó là đúng. Gốc rễ của mọi sản phẩm phần mềm là lập trình. Song nếu như vậy, ngành công nghiệp phần mềm sẽ là quá chật hẹp; và những nhà tư vấn cần phải làm phức tạp nó lên, để mở ra nhiều vị trí khác, nhiều công việc khác. Tư tưởng này được đẩy tới những nhà quản lý, và họ thành ra không coi trọng vấn đề lập trình; họ hiểu rằng để làm ra sản phẩm phần mềm phức tạp, thì tổ chức phải cần những phương pháp phức tạp; và nhiều công việc, nhiều quản lý chính là cách hiện thực hoá điều đó. Có lẽ eXtreme Managing sẽ được lòng hơn là eXtreme Programming.

Và thế là, ba, thị trường XP ngày càng yếu. Những nhà tư vấn, đào tạo không hào hứng với việc đào tạo XP. XP là những gì hand-on rất cụ thể, tốn kém hơn, nhưng nhu cầu ít hơn, là mảnh đất khô cằn của thị trường tư vấn, đào tạo; trong khi những phương pháp quản lý tiếp tục lên ngôi trên một mảnh đất màu mỡ hơn. Và do ít được đào tạo, XP ít được biết đến và ít được thực hành; nên dữ liệu cũng ít, nên càng khó chứng minh được sức mạnh một cách rõ ràng.

Vậy là XP chết.

Đó là tình hình ở Việt Nam. Trên thế giới? XP cũng đã chết. Ít nhất là cái tên.

Ở Việt Nam, các tổ chức không coi trọng XP, họ coi trọng những phương pháp luận về quản lý dự án và quản lý tổ chức mới. Họ mải miết với việc xây dựng môi trường làm việc thân thiện, vui vẻ. Nhưng vui vẻ sao được khi chất lượng sản phẩm không cao? Vui vẻ sao được khi các lập trình viên phải fix bug trên production? Phải căng thẳng khi merge code và lo lắng rằng việc deploy không thành công? Phải để tester chờ tới đêm mới có một bản build?

Trên thế giới, trừ một số người “học hành tử tế”, bây giờ cũng ít ai nhắc tới XP. Nhưng thực tế lại trái ngược hoàn toàn. TDD, pair programming, code refactoring… là những khái niệm và thực hành rất căn bản, ai cũng có thể làm. Continuous Integration (với Jenkins, TeamCity…) xuất hiện ở mọi dự án, đến nỗi người ta không nhớ rằng đó là practices của XP, trừ những người nghiên cứu chi tiết. Và XP chết vì nó đã trở thành bình thường, trở thành “chuẩn” kỹ năng của mọi lập trình viên, không còn là eXtreme nữa. XP là extreme của những năm 2000. Sau gần 20 năm ra đời, XP giờ đây là chuẩn theo nghĩa phổ thông. Hãy thử tìm xem có IDE nào tử tế không hỗ trợ unit test và TDD? Hãy thử tìm xem có framework nào tử tế không có test?

Trong khi thị trường thế giới cạnh tranh gay gắt về những công cụ hỗ trợ tư tưởng, thực hành XP, thì ở Việt Nam, chúng ta vẫn chưa dùng nhiều. XP chết, ở hai nơi, theo hai cách khác nhau.

Tiêu đề rất kêu này của Hiệp Lê. Nhưng nội dung thì cả Hiệp và Hiển đều có chung ý tưởng và hoàn toàn đồng tình.

1,202 total views, 1 views today

Đây là vấn đề cốt lõi cần được giải quyết của việc chuyển đổi sang môi trường Agile.

Push system (hệ thống đẩy) là mô thức quản lý phổ biến hiện nay, sử dụng một quy trình được đinh nghĩa trước cùng các vai trò và mô tả công việc tương ứng. Mọi công việc được chỉ định tới một thành viên cụ thể, quy định từng mức trách nhiệm và khả năng quyết định. Trong một hệ thống phân cấp, mọi công việc đều:

  • cần phối hợp và báo cáo cho người quản lý trực tiếp;
  • thực hiện bởi người ở mức thấp hơn trong phân cấp quản lý.

Thông qua việc định nghĩa rõ ràng sự phân cấp trong mô hình tổ chức, mọi công việc đều được định nghĩa cụ thể về mục tiêu, thời điểm hoàn thành, tiến độ… giúp người quản lý thực hiện việc push công việc xuống những nhân viên như commandcontrol được những gì đang xảy ra; chất lượng công việc phụ thuộc lớn vào tài năng của những nhà quản lý. Push system dựa trên giả định rằng những nhân sự không có động lực làm việc và luôn cần được giao việc và giám sát để hoàn thành.

Cuối thế kỷ 20, Peter Drucker lần đầu nói về thời đại của những lao động tri thức, những công việc trở nên phức tạp hơn, và cần nhiều kỹ năng để hoàn thành hơn. Hệ quả là sự bất hợp lý trong việc phân chia và giao từng công việc cụ thể tới một cá nhân; mô hình làm việc nhóm với những thành viên có đầy đủ kỹ năng trở nên thắng thế. Và bước phát triển tiếp theo là nhóm tự quản.

Pull system (hệ thống kéo) là mô thức quản lý được điều hướng bởi giá trị và kết quả; những công việc được xây dựng thành một danh sách cần hoàn thành theo một thứ tự nhất định và không được giao cho một thành viên cụ thể; những thành viên trong nhóm sẽ chủ động thực hiện pull công việc và thực hiện. Pull system được xây dựng trên giả định rằng những nhân sự luôn có động lực làm việc và không cần nhiều sự quản lý.

Hiểu được sự khác biệt giữa push systempull system là vấn đề lớn nhất với những tổ chức muốn chuyển đổi sang môi trường Agile. Điều cốt lõi nằm ở:

Cách thức định nghĩa quy trình. Trong push system, quy trình được định nghĩa trước, và thông thường được định nghĩa bởi những người không trực tiếp thực hiện công việc cụ thể, và đặt trọng tâm vào giá trị quản lý. Bộ phận quản lý quy trình định nghĩa ra cách thức thực hiện một chiến lược marketing, những bước thực hiện, tài liệu trao đổi giữa các phòng ban từ việc thiết lập chi phí đến thiết kế hình ảnh, nội dung… song chính họ lại có rất ít kiến thức về cách tạo ra một chiến lược marketing hiệu quả. Quy trình được định nghĩa chủ yếu hướng tới việc giúp những nhà quản lý có cái nhìn toàn cảnh và kiểm soát công việc thông qua chỉ định công việc tới từng cá nhân cụ thể; cho mọi dự án. Nhưng sự cứng ngắc của những quy trình được định nghĩa sẵn làm hạn chế sự sáng tạo, tạo ra rào cản làm chậm quá trình tạo ra giá trị thực sự. Push system và Agile hướng tới thực nghiệm. Thông qua việc thực hành và đo đạc hiệu quả, nhóm tự tổ chức biết cách thực hiện nào là phù hợp cho nhóm trong từng hoàn cảnh cụ thể, và hình thành quy trình riêng cho nhóm; từ đó loại bỏ rào cản và tối ưu giá trị tạo ra.

Trách nhiệm hoàn thành công việc. Điều khiến mọi người phân vân là trách nhiệm cá nhân trong pull system: nếu một công việc không được chỉ định cho một cá nhân cụ thể, điều gì khiến công việc đó được hoàn thành? Đây là một câu hỏi hợp lý; song suy nghĩ theo một cách khác, nếu mọi công việc được chỉ định theo cá nhân cùng KPI tương ứng, những cá nhân này có thể vì tập trung nỗi lực hoàn thành một phần việc cụ thể mà bỏ qua việc cộng tác trong bức tranh toàn cảnh và tạo ra giá trị lớn hơn. Một tester được giao nhiệm vụ cụ thể sẽ cố gắng tìm ra thật nhiều bug thay vì cộng tác với developer trong nhóm nhằm tìm cách hạn chế chúng. Pull system và Agile hướng trọng tâm vào xây dựng nhóm có động lực làm việc – tập trung vào con người. Nhưng đó là cách làm phù hợp với thị trường lao động tri thức ngày nay khi nhu cầu người lao động đi dần lên phía đỉnh của tháp Maslow.

Chất lượng công việc. Công việc được nâng cao khi người thực hiện hiểu được giá trị và có cái nhìn thổng thể. Push system thường chỉ tập trung vào từng công việc cụ thể và bỏ qua góc nhìn về toàn cảnh hệ thống và giá trị, mức độ quan trọng cụ thể của một thành phần công việc tạo ra giá trị chung. Pull system cung cấp góc nhìn toàn cảnh, những giá trị đóng góp của từng công việc cụ thể tạo thành giá trị chung, hỗ trợ việc ra quyết định chính xác hơn. Cách vận hành kiểu thực nghiệm của pull system cũng giúp nhóm tìm ra quy trình cho chính mình, giúp loại bỏ trở ngại, tăng năng suất và chất lượng công việc.

Về cơ bản, push systempull system khác nhau về hệ quy chiếu đo lường và đánh giá. Push system đo lường và đánh giá số lượng và khối lượng những công việc được hoàn thành; song cả số lượng và khối lượng công việc được hoàn thành không đại diện cho giá trị được tạo ra. Ngược lại, pull system đo lường và đánh gía dựa trên giá trị được tạo ra.

2,461 total views, no views today

I had a talk in monthly meetup of hocvienagile.com, July. Here is the slide. In fact, some few words in the slide cannot express my idea clearly while our discussion was very interesting. It’s not easy to write these ideas in a short article but it’s nice for some notes:

  1. Agile is for speed, budget…? No. In business perspective, Agile is for value;  in development’s view, Agile is for quality. Agile is a method to adjust / negotiate between the constrains of scope, time and budget to get the highest value / quality in the current situation.
  2. Agile team is happier than non-Agile team. Not sure. If we don’t use the negotiation to adjust these constrains in the right way, Agile team never has chance to be happier.
  3. Agile is built for fast success. No. There are many tricks to get an Agile team successful in the early stage but it’s normally a trap.
  4. Scrum is the best Agile framework. Not sure. About 50% of Agile-share doesn’t show that Scrum is the best Agile framework. Every Agile team should start with Scrum because it’s easier and has clear guideline with specific roles, events…etc.  But when the world is changing fast from development-in-black-box to operation stage, Scrum is going down due to limitation of Sprint goal.
  5. Always say no to ScrumBUT. Not sure. If we are aware that ScrumBUT is being used in reasonable way, it’s fine. Read more here.
  6. Scrum needs 5 core values to success. No. If a team has 5 core values (as Scrum mentions), they would be successful no matter Scrum or another framework is being used. It’s not a required values to start a Scrum team, it’s a target for having high performance team. If a Scrum team doesn’t have, find the right ways from 3 Scrum pillars to get them up.
  7. Agile works without XP practices. No. Never. I have never seen any Agile team (in software development) be successful without XP. XP is the most important thing in Agile umbrella.
  8. Retrospective never talks about people. We should talk about processes, tools and also people. But please do it in constructive way, for both people who give and receive feedbacks. Please not that “Individuals and interactions over processes and tools” is mentioned in Agile Manifesto.
  9. Agile team needs stability, so small turnover-rate is good. Not sure. We also need the new knowledge and change by getting Agile team in a downer stage with new guys.

1,061 total views, 2 views today

Today I had an accident chance to join an interesting meetup about Craftsmanship in Copenhagen when I visited my company’s office. This event was hosted by NNIT that’s a one of the biggest companies in Denmark and spoken by Mark Seemann, a professional programmer, .NET fan and also a consultant.

It’s the first time I join a meetup in Copenhagen so cannot talk much about that but generally it’s quite good today: very professional and nice place, good speaker, great content, good participants, good free foods and drinks – one reason to attract about 200 people (?) 🙂

This talk was dived into 2 parts. In the first one, about 1 hours, Mark was talking about Software Craftsmanship in his viewpoint: making the good code in humance way by activating System 2 (you could find it, System 1 and System 2 in a great book Thinking, Fast and Slow of Daniel Kahneman). It also shows that a good developers need more soft skills such as psychology, communication… in the top of the toolset. After break, he came back to demo session of how to deal with legacy code by refactoring and adding tests. This example is mostly based on the last post on his blog with some update in the model technology like Entity Framework, DataContext, ApiController… instead of ADO.NET,… but the ideas are still there. Of course, his talk was leaded by some well-known books like Refactoring: Improve the Design of Existing Code of Martin Follower, Working Effectively with Legacy Code of Michael C. Feathers, Clean Code: A Handbook of Agile Software Craftsmanship of Uncle Bob… and Code Katas.

Ok, stop taking about him, do about me 🙂

What makes me happy is these content isn’t new for me compared to the content that we have delivered in annual events of Agile Vietnam. Of course, we always learn something from any meetup but if these things are predictable and doesn’t make our brain work hard, it wouldn’t be new. By comparing the topic quality of a developed country like Denmark, I’m proud of and believe on what Agile Vietnam is delivering to community. It stays up-to-date and world-class. At least, Michael C. Feathers has never talk in Denmark but he had in Vietnam 🙂

But I also feel a bit upset. Mark said “Yes, you are too young and don’t know” after he got laughs by talking a story “There are a lot of company have reference architecture design and they might apply C# style to iOS and Android app project”. It sounds funny, of course. But it’s true: “Yes, you are too young and don’t know”. If you ask a young developers about Agile, TDD, CI… they will tell you as it is only way to build the software today. But why don’t we stop talking about it? There are still the “old” men need to know and need to change. So one of our target is the experienced developers who was tight with the old way and might use C# style for iOS project just because it appears in the reference design. But I’m disappointed that it seems experienced developers don’t want to learn more in Vietnam – there are just few old guys in ours meetups.

But where will we go without learning?

1,155 total views, 1 views today

Theo tôi quan sát, database versioning (DB versioning – phiên bản hoá cơ sở dữ liệu – CSDL) thường là vấn đề khó khăn nhất đối với các nhóm triển khai Agile trong việc thực hành CI và CD; thậm chí nhiều nhóm phát triển không nhận ra vấn đề này.

Mọi lập trình viên ngày nay đều hiểu sự quan trọng của những công cụ quản lý source code và có thể sử dụng thành thạo SVN, Git…, tuy nhiên ít người nhận biết được tầm quan trọng và biết cách quản lý những thay đổi trên CSDL. Tại sao lại như vậy? Bởi theo phương pháp phát triển phần mềm truyền thống, CSDL thường được coi như một phần đặc biệt quan trọng và được thiết kế rất chi tiết trong giai đoạn thiết kế phần mềm; và gần như không được phép thay đổi trong quá trình phát triển. Việc thiết kế CSDL cũng thường được thực hiện bởi những người đặc biệt quan trọng nhằm đảm bảo thiết kế tối ưu và đáp ứng tầm nhìn lâu dài của ứng dụng.

Tuy nhiên, phương pháp phát triển phần mềm mới đã thay đổi hoàn toàn cách suy nghĩ và sử dụng CSDL; phương pháp phát triển hướng CSDL (DB oriented programming) đã không còn được sử dụng. Có nghĩa là, CSDL giờ đây chỉ là một thành phần trong phần mềm đơn thuần, không phải là một phần “bất khả xâm phạm”, càng không phải là thành phần đầu tiên được nghĩ tới khi thiết kế kế hệ thống. Dữ liệu vẫn luôn đặc biệt quan trọng, nhưng cấu trúc của dữ liệu (thiết kế CSDL) thì không hẳn. Trong phương pháp phát triển phần mềm Agile, mọi thành viên trong nhóm phát triển đều có thể thay đổi thiết kế DB bất cứ lúc nào nhằm phục vụ cho chức năng mình đang phát triển. Điều này dẫn đến tần suất thay đổi thiết kế CSDL lớn hơn; và vấn đề quản lý thiết kế CSDL cũng phát sinh.

Thứ nhất, khi một lập trình viên thay đổi CSDL, những thành viên khác trong nhóm phát triển không nhận biết được thay đổi này. Vấn đề này được thực hiện rất tốt với source code version control như SVN hay Git; những thành viên trong nhóm chỉ cần check-out là nhận được những thay đổi trên source code. Thứ hai, khi những thay đổi này gây ra xung đột (conflict), nhóm sẽ giải quyết như thế nào? Vấn đề này phức tạp hơn rất nhiều; vì mỗi thay đổi trên CSDL sau khi được áp dụng sẽ không thể roll-back; không đơn giản như cách chúng ta giải quyết xung đột trên source code.

Theo tôi quan sát, những nhóm phát triển thường áp dụng những phương pháp sau:

  • Sử dụng môi trường chia sẻ. Cách dễ nhất (và đôi khi là cách tốt nhất) là sử dụng môi trường phát triển chia sẻ (shared environment); mỗi lập trình viên làm việc trên máy tính của mình với source code được check-out và phát triển hoàn toàn độc lập, nhưng sử dụng chung một DB server. Phương pháp này có rất nhiều điểm lợi, đặc biệt là đảm bảo một môi trường chung với mọi sự thay đổi được cập nhật kịp thời tới mọi lập trình viên. Tuy nhiên, vẫn có ít nhất 2 vấn đề gặp phải:
    • Hiệu năng. Trong phần nhiều dự án (không xử lý dữ liệu lớn), hiệu năng từ việc sử dụng môi trường chia sẻ thấp hơn nhiều hiệu năng xử lý trên máy tính cá nhân (vấn đề đường truyền, phân chia module…); gây ảnh hưởng tới năng suất làm việc.
    • Quản lý revision. Đây là vấn đề không có giải pháp toàn diện. Chúng ta sẽ xử lý thế nào với trường hợp sau: Sau một vài thay đổi, nhóm phát hiện ra rằng một số thay đổi gần đây không đúng và muốn roll-back? Vấn đề này thường xuyên xảy ra giống như việc chúng ta phải revert những commit lỗi khi sử dụng source code version control. Nhưng chúng ta không thể làm vậy với CSDL.
  • Tạo những script tương ứng với từng thay đổi. Ý tưởng ở đây là, nhóm lưu trữ một CSDL ổn định và tương ứng với mỗi thay đổi, từng script sẽ được tạo ra. Trong trường hợp cần revert commit, nhóm sẽ restore CSDL này và áp dụng từng script tương theo tuần tự tới trước commit cần revert. Vấn đề khác có thể nảy sinh, bằng cách nào những lập trình viên biết cách tạo những script theo thứ tự hợp lý khi việc phát triển, commit của họ được thực hiện song song trong khi sự thay đổi trên CSDL cần thực hiện tuần tự? Bằng cách nào nhóm có thể phát hiện ra những xung đột trên CSDL?

Tuy vậy, ý tưởng về việc scripting DB (kịch bản hoá CSDL) là một ý tưởng hay, và được phát triển thành DB versioning. Cơ bản có thể được mô tả như sau:

  • Mọi thay đổi trên CSDL phải được tạo bằng script. Thay vì thực hiện tạo một bảng mới qua công cụ có giao diện người sử dụng, chúng ta viết thành câu lệnh CREATE TABLE và lưu trong file SQL.
  • CSDL cũng được quản lý bởi source code version control. Khi mọi thay đổi trên CSDL là script, chúng ta hiểu rằng CSDL cũng là source code và những file này được quản lý bởi source code version control là điều hợp lý.
  • Mọi script thay đổi trên CSDL gắn với từng phần phát triển phải được commit đồng thời. Ví dụ, lập trình viên thực hiện user story “quản lý khách hàng” cần check-in source code và script tạo ra bảng KhachHang trong một commit. Điều này giúp cho việc quản lý (đặc biệt là revert) trở nên đơn giản hơn.
  • Mọi thay đổi trên CSDL được kiểm tra trong quá trình build hoặc start-up của ứng dụng. Theo tôi, việc kiểm tra nên được thực hiện sớm nhất có thể (tốt nhất là trong quá trình build) nhằm giảm thiểu thời gian lập trình viên nhận biết những thay đổi trên CSDL. Nếu việc áp dụng những script này không thành công, quá trình build hoặc khởi chạy ứng dụng sẽ thất bại; qua đó lập trình viên nhận biết được sự thay đổi và những xung đột đang xảy ra trên CSDL.
  • Các version của sự thay đổi được lưu trữ tại chính CSDL đó. Một cách tiếp cận đơn giản là tạo ra một bảng lưu trữ lịch sử những script đã được áp dụng trên chính CSDL đó.

Kỹ thuật trên sẽ khiến CSDL và những thay đổi trên CSDL (script) được coi là source code; giúp lập trình viên dễ dàng quản lý hơn rất nhiều, cả về tư tưởng lẫn kỹ thuật.

Hiện nay, thị trường cung cấp rất nhiều công cụ hoặc thư viện hỗ trợ việc versioning DB như dbUp, RoundhousE, các sản phẩm của Red Gate…, hầu hết đều có chung tư tưởng trên, và có thể có thêm một số chức năng khác như:

  • Restore DB. Khởi tạo hoàn toàn một CSDL từ các scripts là điều tuyệt vời khi chúng ta có bộ lịch sử đầy đủ; tuy nhiên, quá trình này thường tốn khá nhiều thời gian thực hiện. Cách làm tốt hơn là nhóm phát triển “chốt” một CSDL ổn định, được coi là điểm bắt đầu và chỉ quản lý những thay đổi bắt đầu từ phiên bản này. Sau một khoảng thời gian, một phiên bản ổn định khác có thể được thay thế. Tính năng này nhằm giảm bớt thời gian khởi tạo CSDL nguyên thuỷ.
  • Có thể roll-back khi gặp lỗi. Khi tạo một script cho sự thay đổi, lập trình viên cũng tạo một “roll-back” script. Khi gặp lỗi, công cụ này sẽ thực hiện những roll-back script này theo thứ tự ngược lại giúp CSDL quay lại trạng thái trước khi bị thay đổi. VD: script ALTER TABLE ADD COLUMN Address NVARCHAR(50); có roll-back script là ALTER TABLE Customer DROP COLUMN Address;
  • Sử dụng chính CSDL hiện có lưu trữ sự thay đổi.
  • Tích hợp với những công cụ CI, CD. Đây là một chức năng tuyệt vời khiến việc tích hợp, triển khai chỉ với một nút nhấn; cũng như đảm bảo không gây sai sót bởi con người (rất dễ xảy ra) ảnh hưởng tới môi trường thật.

DB versioning là vấn đề đặc biệt quan trọng và khá nhức đầu trong việc triển khai CD. Tôi sẽ trở lại vấn đề này với một hướng dẫn cụ thể trong bài viết sau.

2,158 total views, 1 views today

Đây là chủ đề nhận được khá nhiều sự quan tâm thời gian gần đây, đặc biệt qua hai sự kiện gần nhất của ITLC. Tuy rằng có nhiều người quan tâm và biết đến DevOps nhưng qua hai sự kiện này, theo đánh giá cá nhân, lượng người “thực sự hiểu biết” không nhiều, đa phần mọi người đánh đồng DevOps và CD; bài viết này mong cung cấp một số thông tin giúp hiểu đúng về DevOps và CD.

CD: Continuous Delivery hay Continuous Deployment?

Những nhóm phát triển phần mềm theo phương pháp Agile thường quen thuộc với kỹ thuật / công cụ tích hợp liên tục (Continuos Integration – CI) nhằm liên tục tích hợp phần tăng trưởng được tạo ra vào sản phẩm giúp kiểm soát tình hình thông qua thực hiện kiểm thử (đặc biệt là integration test, regession test) khiến sản phẩm đạt sự ổn định. Đây là một kỹ thuật / công cụ được thực hiện trong giai đoạn phát triển (development).

Bên cạnh CI, mọi người hay nói đến CD, nhưng lại không thực sự hiểu CD từ viết tắt của Continuous Delivery hay Continuous Deployment và cũng thường cho rằng hai khái niệm này là giống nhau. Thực tế là:

Continuous Delivery, giống như CI là một tập hợp những kỹ thuật / công cụ đảm bảo việc triển khai (deployment) được thành công bằng việc liên tục chuyển giao (delivery) những phần tích hợp lên môi trường staging (thường là rất giống với môi trường production). Bằng việc liên tục kiểm thử trong môi trường staging, phần mềm đảm bảo đủ chất lượng để deploy qua production; những deployable artifact này vẫn chỉ tồn tại trên staging và không được deploy tự động qua production.

Continuous Deployment, đúng như tên gọi, là một tập hợp những kỹ thuật / công cụ đảm bảo việc tự động hoá toàn bộ quá trình từ development đến production. Continuous Deployment được coi là bước phát triển của Continuous Delivery, hoàn tất giai đoạn chuyển giao đến người dùng cuối.

Có thể so sánh CI, CD đơn giản thế này:

  • Continuous Integration: Tập trung vào source code, tạo sự “tự tin” về source code qua unit test, integration test, tạo ra staging-ready-artifact.
  • Continuous Delivery: Tập trung vào artifact và môi trường (environment), tạo sự “tự tin” về deployable-artifact qua acception test, tạo ra production-ready-artifact.
  • Continuous Deployment: Tập trung vào người dùng cuối, tạo ra production-deployed.

Continuous_Delivery_Continuous_Deployment

Vậy: Continuous Delivery hay Continuous Deployment?

Nhưng tóm lại là Continuous Delivery và Continuous Deployment khác gì nhau? Rất nhiều người vẫn bị nhập nhằng giữa 2 nguyên tắc này. Lý do là: nếu staging là môi trường giống với production, thì khi đã làm được Continuous Delivery thì đương nhiên chúng ta cũng làm được Continuous Deployment (đều là deploy qua 1 môi trường, vậy thôi). Đúng. Về mặt kỹ thuật là như vậy. Vì vậy, những công cụ như Pupet, Octopus, Ansible… đều được sử dụng cho CD (còn ai hiểu CD là gì thì tuỳ ngữ cảnh, deploy tới staging thì là Delivery; deploy tới production thì là Deployment). Nhưng công cụ không phải thứ quan trọng nhất.

Thứ nhất, staging không phải production. Dù chỉ cần 1 cấu hình đơn giản là artifact được deploy qua bất cứ đâu. Nhưng chúng ta có đủ “tự tin” để việc deploy qua production được thực hiện tự động?

Thứ hai, staging vẫn không phải là production. Production luôn cần ổn định và mong muốn zero-down-time, staging thì không cần thiết.

Với những single-user-app như ứng dụng chạy trên PC, mobile… thì khá đơn giản, tôi không bàn tới. Với web app, các tổ chức thường dè dặt trong việc triển khai Continuous Deployment vì những lý do trên.

Về lý do thứ nhất, tổ chức chỉ có thể thực hiện Continuous Deployment khi hệ thống QA được thực hiện tự động hoặc “gần như tự động” với phần tích hợp để chắc chắn rằng sản phẩm đủ chất lượng và triển khai đúng thời điểm một cách tự động – đây là vấn đề tương đối phức tạp.

Về lý do thứ hai, cách làm phổ biến là sử dụng kỹ thuật “blue-green deployment”, deploy lần lượt từng phần hệ thống với HAproxy đứng trước nhằm đảm bảo traffic được route tới những phần đã được deploy thành công (green, version mới); trước đó traffic được route tới những thành đã chạy ổn định (blue, version cũ). Vấn đề sẽ trở nên phức tạp khi phần green và blue có nhiều sai khác về business logic dẫn đến không toàn vẹn dữ liệu. Đây là một trong những cản trở lớn nhất khiến tổ chức không “tự tin” với việc deploy tự động (tôi sẽ trình bày trong một bài viết khác).

blue_green_deployments

DevOps

Như bạn thấy, CD dù là Continous Delivery hay Continuous Deployment thì vấn đề phức tạp không phải là kỹ thuật hay công nghệ. Và DevOps cũng vậy.

Việc liên tục triển khai dẫn đến nhu cầu cộng tác chặt chẽ giữa nhóm phát triển (development) và nhóm vận hành (operation) và cách phân chia tổ chức theo nhóm chức năng (functional team) trở nên lỗi thời; cách làm việc liên chức năng (cross-functional) sẽ hiệu quả hơn rất nhiều. Và đó là DevOps. DevOps = Development + QA + Operation.

Như vậy DevOps thực sự là sự chuyển đổi trong tổ chức về cách làm, văn hoá (trong cách tổ chức nhóm, cộng tác…) và kỹ thuật, công nghệ nhằm linh hoạt hơn và nhanh chóng phản ứng với sự thay đổi xuyên suốt quá trình từ phát triển tới triển khai đến tay người dùng cuối với chất lượng đảm bảo một cách nhanh nhất.

Tại sao DevOps phức tạp? Vì DevOps thực sự tạo ra một văn hoá cộng tác để chuyển giao sản phẩm theo cách mới. Theo quy trình phát triển phần mềm cổ điển, các nhóm development, QA, operation hoạt động rất riêng biệt với những kỹ năng, văn hoá khác nhau. Giờ đây họ đứng cùng nhau với một mục tiêu chung và một văn hoá chung. Điều này không thể có trong một thời gian ngắn.

Tại sao DevOps thông thường nhanh thành công hơn trong môi trường Linux? Tôi lưu ý là thông thường. Vì thông thường, nhóm opeartion sử dụng Linux quen thuộc hơn với việc sử dụng câu lệnh, lập trình (viết script…); so với Windows, nhóm sử dụng công cụ đồ hoạ để cấu hình. Và CI, CD nói chung làm việc nhiều với dòng lệnh.

Một nhóm toàn developer có thể thực hành DevOps? Hôm trước, anh Trịnh Minh Cường có nói rằng “nhóm của anh toàn dev, làm DevOps tốt”. Đúng, vì bản thân nhóm phát triển đã có thể build, run phần mềm trên môi trường local thì hoàn toàn có thể triển khai đến production và CD là điều nằm trong tầm tay. Nhưng đó mới chỉ là kỹ thuật. Developer thường không có kiến thức về hệ thống, vận hành như operator. Đơn giản như cấu hình quyền thư mục, chmod 777 giúp họ chạy, test hoàn toàn tuyệt vời trên local nhưng sẽ là thảm hoạ trên production. Chính vì vậy, tổ chức cần sự kết hợp kiến thức, kỹ năng của cả developer, QA, operator để triển khai DevOps thành công.

Và xu thế?

Trong bài nói chuyện của CTO Automic tại ITLC, có nói đến heuristic CD khiến tôi liên hệ tới 2 xu thế chính hiện nay.

Một là, tính agility được mở rộng theo bề ngang của tổ chức. Bắt đầu bởi Agile software development; tiếp đến là DevOps khiến Dev và Ops gắn kết hơn; tiếp đến là NetOps khiến Net và Ops (thậm chí là Dev-Ops-Net) gắn kết hơn.

Hai là, tính agility được nâng cao dần. Bắt đầu bởi manual delivery / deployment; tiếp đến là CD khiến việc delivery / deployment tự động; tiếp đến là heuristic CD khiến việc delivery / deployment tự động ở mức độ “thông minh” hơn, tự động nhưng đúng thời điểm và có “trí tuệ” như manual delivery / deployment.

Những vấn đề này hơi phức tạp một chút, hy vọng tôi có thể trở lại trong một bài viết gần. Ngoài ra, bạn có thể tham khảo những bài viết ở dưới:

http://martinfowler.com/bliki/ContinuousDelivery.html

http://martinfowler.com/bliki/BlueGreenDeployment.html

3,136 total views, 1 views today