Following my post about How programmer gets his wife happy, here is a simpler version for who is using Mac with Message app.

Forget all Twilio setup, you just need to create the cronjob. Replace the content and your wife’s number.

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.

Life is easy if you are a programmer.

546 total views, no views today

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 😉

533 total views, 1 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.

216 total views, no 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.

592 total views, no 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.

1,080 total views, no views today

I had a talk in monthly meetup of hocvienagile.com, July. And here is a slide. In fact, some few words in the slide cannot express my idea clearly enough 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 while Agile is for quality in developer’s view. 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 a 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.

208 total views, no 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?

630 total views, no 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.

1,463 total views, no views today