Founders
need to get their Product Development strategy right. Right from the
word go. Getting it wrong means, having to pivot somewhere down the
line. And this costs time and money. How can the founder reduce the risk
of getting it wrong? The picture below says it all.
A picture is worth a thousand words. Indeed, this one is. The problem here is to build a car.
The
wrong way to go about it is, to build a car by putting the required
parts together. In this case the founder is only looking at its form.
He will end up with a costly process, before he realises he can’t do
better than the Toyota’s and BMW’s. (This is only a metaphor).
To
understand the right way to go about it, we need to look at the bottom
process, from right to left. The car is a vehicle that transports
people. We are reducing its functionality step by step.
Reduce the number of people it can transport to one — motorcycle. (We will fix that problem later)
Remove its self propelling capacity — bicycle. (We will fix that later)
Remove its power transmission — we have something like a skateboard with steering now.
Remove steering — skateboard.
You
may a have noticed by now, that we reduced a car to a skateboard. Yet
we retained the functionality. Transporting people. Which is indeed also
the function of a car.
It is all about starting with the core function.
The
founder has to start Product Development with the core function. This
is the core of the founders idea, problem and solution. This is what the
initial brainstorming of the team has to arrive at. Then it is a set of
iterations of product development and market analysis until you have
the minimum viable product.
Đâ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:
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.
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 }
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.
