DevOps

Đâ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.

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).

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

Cảm ơn các bạn bên gurunh.

Cơm thêm: bài nói chuyện DevOps của chị Nicole Forsgren tại Goto 2015, Berlin

Bài gốc ở đây

Getting Started With Automation

In the past months I worked with a number of team setting up continuous integration and delivery infrastructures, and helping with their all around automation and testing. A common thing that I've seen is that while we all agree that having automation is important is not always easy to know where to start, and one could feel overwhelmed.
In my opinion there are two places where to start looking for automation candidates in your development work flow: mindless repetitive things, and actions that require multiple steps in which we might forget one, or make a mistake in one point of the process that would propagate to all the others.
Mindless repetitive things are the automation low hanging fruits because by being mindless they are the easiest to describe in a script for a machine to execute, and by being repetitive you will get a lot of value by automating them, as you will run your script multiple times.
The possible gain in automating tasks that require multiple steps is more subtle, but also bigger. Tasks that require multiple steps are harder to remember, usually need some kind of documentation or checklist, and the making a mistake in one step breaks all the following ones. If instead of relying on your memory or a checklist that might or might not be up to date you describe the process in an automation script not only you make sure that each step will be executed with the right inputs and in the right order, but also create a documentation that is live and always up to date.

Example of Automation in iOS Development

Bumping the version and build number of the project, and eventually commit the change

These two action are always the same, and they consist in a simple edit to a file, which can be easily executed by a script which can then take care of calling git to commit the change.

Generating code coverage reports

If you work with enterprise clients chances are that they'll require you to produce documentation regarding your test coverage. Tools like slather can be used to generate a report based on Xcode code coverage. You can even go a step further and manipulate the gathered data into a pdf and automatically send it via email.

Running unit and acceptance test

To generate test coverage reports you need to have run the tests first, and its always best to run them as a pre-step before every code coverage data generation. Running your tests via a script is very simple, and once you have it in place hooking up a CI system will be as easy as configuring it to run your script.

Building, archiving, and exporting your app for distribution

This is a good example of a process that requires multiple steps, and in which an error in one step might compromise the next one. Stop manually changing the code signing identity and provisioning profile, waiting for the archive action to complete and its result window to appear, and then click the export button. Define which configuration, identity and provisioning profile to use in a script, and let it string together the steps needed to produce an ipa.

Distributing your app to betatesters

Uploading a build to a beta distribution platform usually requires using an app provided by them, or going on their website. Chances are your provider has APIs that you can use to upload the build from a script instead, so that you only have to press one button.
The nice thing about this is that it can be added as an extra step to the previous one, so that you can build an ipa and distribute it all in one go.

Environment Bootstrap

Another example of processes that require multiple steps and for which the documentation might not be up to date is setting up the development environment after a fresh clone of the repository. You might be needing extra tool installable via Homebrew, Ruby gems, etc., fetching dependencies. It is easy to write a script that checks for every required tools, installing them when possible, and calls any other command with multiple parameters required to bootstrap the dev environment.

---

These are only some ideas to help you get started automating your workflow and increasing your productivity. Ideally everything that can be automated should be automated, just pick some low hanging fruit and start gaining back time.
Another cool thing is that automation works as effectively for individuals as it does for teams, so you can practice by yourself and then introduce your automation scripts to the rest of the team when you think they're good enough to share.
I'd love to hear from you regarding what you have automated and what to plan to automate, you can leave a comment below or get in touch on Twitter @mokagio.
Leave the codebase better than you found it.

Source

When to use map, flatMap, or for loops in Swift

Use map when you need to transform arrays

let arrayOfNumbers = [1, 2, 3, 4]
let arrayOfString = arrayOfNumbers.map { "\($0)" }

In the context of Array map get an array, applies a transformation function to every element, and returns a new array with the resulting elements. . That's the best use case for map.

Use for loops when there are "side effects"

Without going into details an operation has a side effect if it results in some kind of state changing somewhere, for example changing the value of a variable, writing to disk, or updating the UI. In such case using a for loop is more appropriate.

for number in arrayOfNumbers {
  print(number)
}

And what about flatMap?

When you need to transform the contents of an array of arrays, into a linear array use flatMap:

let users: [User] = ...
let allEmails = users.flatMap { $0.emails }

p/s: No difference about performance.

Thanks to this

Build Apps Faster Than Ever Before

Setup an Xcode Derived Data RAM Disk

Would you prefer the time it takes to compile and link your app to be faster or slower?

If you are not using a RAM disk, then you may be choosing the latter answer. If you don’t already know how to set this up, I’ve created an easy to use script written in Swift 2.2. This one may best suit the pros but we can all appreciate a little less waiting for a computer.

As a side note, Swift may not currently be the most efficient way to write scripts, but being able to do it has a special kind of sparkle that lights up when it is done.

Using the script allows the Derived Data setting to stay the same in Xcode but runs out of RAM instead of the disk. It does this by mounting the RAM disk to the same path that is normally disk-based.

This saves wear-and-tear on solid state drives, if you are into that kind of thing. If you happen to be using a spinning disk, it’s way faster than that, too.

I’ve been running Xcode like this for years and over that time all those savings can really add up.
It’s easy to create a launch agent, simply a property list file, that allows having the script run every time your computer starts. I’ve included an example of that in the source code.
I’ve even made sure using this technique works with Instruments because there is a need for Spotlight to find symbol files during profiling and debugging.

The script is contained in an Xcode project. The file main.swift can be copied out and renamed to setupXcodeDerivedDataRAMDisk.swift and placed in a bin directory for running from the command-line or a launch agent.
Here is the link to the project.

Original post

VIPER or not VIPER?

https://swifting.io/blog/2016/03/07/8-viper-to-be-or-not-to-be

The sketchyTech Manifesto

 1.  Sharing as you learn has value
Aside from the fact that to become fully versed in any technology where the sands are always shifting is a near impossibility, it is true that learning from a learner holds its own value.

Once our learning is complete (or near to complete) all of those daunting documents become less daunting and we forget why we were ever scared by the small things (and what those small things even were). It becomes necessary in the position of accomplished expert, therefore, to imagine ourselves back into the role of learner. The recent learner, meanwhile, has only just been to the place where the learner close behind has just arrived. He or she remembers the path exactly and can guide the fellow learner across the bumps, smoothing the way as they go.

2.  Stand up and be corrected
It is important that we blog as we learn. Not only to guide others and as a record for ourselves, but also so that we can be corrected by people another step or more ahead, or on another path altogether. After all we all learn by our mistakes and the humiliations we suffer.

3.  It is important to acquire knowledge across a broad range of technologies
Learning about how to script something in JavaScript and then doing the same thing in Objective-C is valuable because we learn new ways to structure and order code. We learn the most useful ways to organise data and carry different ideas across our practice.

This is one example among many of the way in which allowing knowledge to pass across boundaries helps it to grow. There is no end to the combinations that will help you learn.

4.  Keep things as short as possible
Specs and documentation are often bloated, disorganised, spread across unlinked areas of a website. Lots is out of date and sometimes deprecated. Examples are often too long and need lengthy unpicking to find the piece of the puzzle you are missing. It is better to have lots of small, short examples that teach single things people will want to know without the surrounding cruft of a make-believe app.

5.  Listen to others and be inspired
Your social networks are full of people asking questions. Be inspired by people on twitter, Facebook, LinkedIn, Quora, Coderwall and StackOverflow to answer questions, to go further with ideas than others do. Use the opportunity of a blog to do more, but at the same time value its immediacy and the ability to respond to the needs of others quickly.

6.  Don't be put off by people who tell you that you don't know what you're talking about
Your work is of value to those in the same position as you. Your writings are not the final truth, they are a stepping stone to further, more exact knowledge.

One day the people who learnt from you will know more than you, but only because you were one of the people who took the first steps with them.

7.  Experiences from different fields add value to this one
ebooks and publishing-related technologies are a hybrid. People with IT degrees are of no more or less value than those with backgrounds in the traditional publishing industry. We need to work towards understanding the worlds of one another in order to progress and make good stuff. We need people who are bridges as well. Between programmers and art, between publishing and electronics, between typography and technology, between authors and the W3C, between indexers and the IDPF, and so on and so on. Don't treat each other like idiots.

http://sketchytech.blogspot.com/p/the-sketchytech-manifesto.html

9 trở ngại của người Việt Nam khi làm việc nhóm

Nhóm đóng vai trò quan trọng nhằm đảm bảo năng suất và chất lượng công việc. Trong khủng hoảng, cắt giảm nhân sự trở nên thường xuyên. Cắt giảm nhân sự bắt buộc các nhân viên phải làm nhiều công việc hơn và đảm đương nhiều hơn một vị trí. Trong thời hoàng kim nhóm làm việc quan trọng và trong thời gian khủng hoảng, nhóm làm việc trở thành yếu tố quyết định để giải bài toán khủng hoảng “ Làm nhiều hơn với nguồn lực ít hơn”. Khi các nhân viên trong nhóm cộng hưởng tốt, kết quả tạo ra sẽ vượt trội hơn tổng của toàn bộ cá nhân trong nhóm. Các công ty nước ngoài và liên doanh tại Việt Nam rất hiểu triết lý đó do vậy các chương trình đào tạo Team Building được quan tâm và chú ý đặc biệt. Trên thực tế, các công ty Việt Nam không có ngân quỹ nhiều cho hoạt động đào tạo cũng có thể định hướng phát triển nhóm hiệu quả thông qua các hoạt động đào tạo, thay đổi nhận thức của nhân viên. Các chương trình này có thể tập trung vào một số rào cản làm việc nhóm cố hữu của người Việt Nam như sau

1. Chứng tỏ cái tôi hay năng lực cá nhân

Các nhân viên Việt Nam khi hoạt động trong nhóm thường hay bày tỏ và tìm cách chứng minh năng lực hoặc cá nhân mình. Nhóm không phải là sân khấu để một ca sỹ hay nhạc công tìm cách thể hiện mình. Một biểu hiện thường thấy của tính cách này đó là hay chỉ trích và phản đối ý kiến các thành viên khác trong nhóm. Tuy nhiên bản thân họ sẽ không có bất kỳ một giải pháp hay sáng kiến nào thậm chí khi họ phê phán và chỉ trích kịch liệt những người khác. Nhóm chỉ có thể sáng chói khi hoàn thành nhiệm vụ được giao. Các thành viên nhóm không thể tự hào về mình trong hoàn cảnh nhóm thất bại.

2. Biết nhiều nhưng không biết sâu

Nhóm thể hiện triết lý phụ thuộc lẫn nhau trong môi trường kinh doanh của thế kỷ 21. Công việc đòi hỏi rất nhiều các kỹ năng, kiến thức sâu và hẹp. Năng lực con người là có hạn và tri thức là vô hạn. Mỗi thành viên nhóm cần phải có những chuyên môn đủ sâu để giải quyết các vấn đề yêu cầu. Như vậy, các thành viên sẽ thiếu những kỹ năng khác mà họ có được từ nhóm. Các nhân viên Việt Nam thường không tập trung sâu vào các lĩnh vực. Chính vì như vậy họ thường hay biểu lộ như lý do một về bề rộng của chuyên môn thay vì bề sâu.

3. Tiếp cận vấn đề theo triết lý Thua- Thắng

Các nhân viên Việt Nam thường tiếp cận vấn đề theo triết lý thua- thắng khi đòi hỏi quyền lợi cho bản thân cá nhân nhiều hơn trong khi không quan tâm tới quyền lợi của nhóm và các thành viên khác. Triết lý thắng – thắng không được áp dụng trong suy nghĩ và hành xử thường ngày để nhằm làm to thêm chiếc bánh của toàn nhóm. Thông qua cơ hội đó mỗi cá nhân sẽ có kết quả nhiều hơn.

4. Quên đi đại cục và tập trung vào tiểu tiết

Suy nghĩ thua-thắng là tác động tạo ra điểm yếu thứ tư khi các nhân viên Việt Nam tập trung vào tiểu tiết thay vì đại cục. Ngoài ra lý do một cũng là yếu tố tác động quan trọng cho lý do này. Thay vì tìm các tiếp cận hệ thống giải quyết vấn đề, các nhóm việt nam sa đà vào các tác vụ giải quyết tiểu tiết hàng ngày.

5. Suy nghĩ cảm tính không dựa trên dữ kiện và tư duy logic

Các nhân viên Việt Nam thường tranh luận ít dựa trên dữ kiện và tư duy logic. Các vấn đề thực tiễn cần được nghiên cứu, đánh giá một cách khách quan. Ngoài ra yếu tố kinh nghiệm cũng là một trở ngại trong quá trình làm việc nhóm.

6. Văn hóa làng xã – nể nang không phê bình khuyết điểm

Tâm lý ngại va chạm thủ thế khiến cho các nhân viên Việt Nam không kiên quyết phê bình và đấu tranh khi các thành viên nhóm không hiệu quả. Bản thân cá nhân có thể được lợi nhưng toàn bộ nhóm sẽ không đạt kết quả tốt. Suy nghĩ làm việc cho qua chuyện cũng là một yếu tố làm trầm trọng thêm khuyết điểm này.

7. Không tách biệt vấn đề và con người

Khi mâu thuẫn xẩy ra, các nhân viên Việt Nam thường không tách bạch con người và vấn đề. Thay vì bàn luận vấn đề, các nhân viên Việt Nam thường chỉ trích cá nhân người có ý kiến đi ngược với mình. Thói quen này có thể là nguyên nhân rất trầm trọng làm giảm tính hiệu quả của nhóm. Tác giả đã gặp trên thực tế một việt kiều tên D khá nổi tiếng trong giới công nghệ thông tin tại Việt Nam và được giáo dục đào tạo trong môi trường phương Tây. Khi tranh luận với những ý kiến trái chiều ông ta thường hay sử dụng những từ ngữ không lịch sự đả phá những cá nhân có suy nghĩ trái chiều mình. Qua ví dụ đó để thấy rằng những gì thuộc bản chất rất khó thay đổi trong cuộc sống. Sự tôn trọng là nền tảng căn bản của nhóm hiệu quả và là sự khởi đầu của những tranh luận tích cực.

8. Không tuân thủ quy trình và các luật lệ của nhóm

Khi gia nhập nhóm, các thành viên cần hạ bản thân cá nhân thấp hơn nhóm làm việc. Các nhân viên Việt Nam thường không tôn trọng qui trình và các luật lệ. Một ví dụ đơn giản khi họ thường không giao nộp các phần việc làm đúng thời gian qui định. Hiện tượng này làm giảm hiệu suất của toàn nhóm.

9. Giao tiếp không hiệu quả

Nhóm hiệu quả bắt buộc các thành viên giao tiếp hiệu quả trong quá trình làm việc. Các thói quen xấu trong giao tiếp như nói nhiều hơn nghe, không truyền tải thông tin đầy đủ, luôn luôn trả lời hiểu mặc dù chưa hiểu hết v/v thường xuất hiện trong các nhóm làm việc tại Việt Nam.

(Theo Quanlycaptrung.vn)