How do you deal with ever increasing build times and collaborate more without sacrificing on collaborating? That is what this talk is about.

1. Why is my build
times so long?
1 / 63

2. My name is Kevin
I like community
organizing
and biking 🚴
2 / 63

3. Who here has tried
waiting for your
computer/CI to finish
the build?
3 / 63

4. I don't like waiting
4 / 63

5. What is long build
times?
5 / 63

6. waiting == less
productivitiy
less productivity == less
money
less money == you die
6 / 63

7. builds are inevitable
7 / 63

8. 8 / 63

9. Build time scales
linearly
Time
Buildtime
9 / 63

10. We are building
bigger and better
apps
10 / 63

11. Companies have
bigger engineering
teams than ever
11 / 63

12. ✅Consistent builds
12 / 63

13. ✅Docker 🐳
13 / 63

14. So how we used to
solve it:
14 / 63

15. Wait on machines getting
faster aka.
Moore's law
15 / 63

16. 2 techniques we can
use:
16 / 63

17. 1. Caching
2. Do less
(3. Optimize)
17 / 63

18. Everyone uses
webpack
18 / 63

19. Wait!? Let's look if they
already solved it!
19 / 63

20. 20 / 63

21. 1. Caching
There are only two hard things
in Computer Science: cache
invalidation and naming
things. -- Phil Karlton
21 / 63

22. Knowing what has
been cached and has
not
22 / 63

23. Saving and retriving
cache
23 / 63

24. 2. Do less
Removing code so that it
doesn't get run
24 / 63

25. Using multiple
repositories
25 / 63

26. The problem is:
collaborations
problems
26 / 63

27. There is a difference:
your company code !=
open source code
27 / 63

28. Example:
28 / 63

29. Project A + UI library
2 min | 2 min
29 / 63

30. Project A
UI Library
30 / 63

31. Project A
Project B
UI Library
31 / 63

32. Project A
Project B
UI Library v.1
32 / 63

33. Project A v.1
Project B v.1
UI Library v.1
33 / 63

34. Project A v.1
Project B v.1.1
UI Library v.1.1
34 / 63

35. Project A v.1.2
Project B v.1.1
UI Library v.1.2
35 / 63

36. Project A v.1.2
Project B v.2
UI Library v.2
36 / 63

37. NIGHTMARE!
37 / 63

38. That is why public
packages
left-pad?
38 / 63

39. So how do we solve
it?
39 / 63

40. We need a tool that:
- define
dependencies
- watch files changes
- language agnostic
40 / 63

41. projectA/
index.js
projectB/
index.js
projectC/
index.js
library/
lib.js
41 / 63

42. projectA/
index.js*
projectB/
index.js
projectC/
index.js
library/
lib.js
42 / 63

43. projectA/
index.js*
projectB/
index.js
projectC/
index.js
library/
lib.js
Builds started:
- projectA ...
43 / 63

44. What if a library
change?
44 / 63

45. projectA/
index.js
projectB/
index.js
projectC/
index.js
library/
lib.js*
Builds started:
- library ...
- projectA ...
- projectB ...
- projectC ...
45 / 63

46. Watch files changes
It tracks content of file
46 / 63

47. bazel.build can help
with that
47 / 63

48. copenhagenjs.dk uses
it
48 / 63

49. at first I didn't
understand
49 / 63

50. Bazel is also weird!
JavaScript is not 1st
class citizen!?
50 / 63

51. Python like Syntax
genrule(
name = "build",
srcs = ["server.js"],
cmd = "cat $< > $@",
outs = ["server.min.js"]
)
51 / 63

52. Great rules:
- Not allowed to
depend on ".."
- Copies files to
temporary folder
52 / 63

53. src/
index.js
⇣
temp/
# puts files here!
⇣
output/
# detects if you write to here!
53 / 63

54. It doesn't allow
circular dependencies
A -> B -> A
54 / 63

55. Automatically
Output of one task ->
input next task
55 / 63

56. genrule(
...
outs = ["build.tar.gz"],
)
genrule(
srcs = ["build.tar.gz", "firebase.json"],
...
)
56 / 63

57. Future for me:
- Store the state on
S3 or GCS
57 / 63

58. No more ✅:
Change 1 line in
markdown
All JavaScript tests
run!
58 / 63

59. Don't accept slow
builds!
Don't accept terrible
collaboration!
59 / 63

60. Do break up your
builds to many small
builds
Do encourage
collaboration!
60 / 63

61. I really encourage you
to use Bazel
Even seniors are
juniors with bazel
61 / 63

62. Thank you!
Questions?
Check out
kevinsimper.dk
62 / 63

63. 63 / 63