Beautiful Builds and Build Patterns by Roy Osherove @RoyOsherove #devsum13

Automate All The Things
Beautiful Builds

My book - Beautiful Builds - contains common patterns that we use in automated builds.

What if I told you, that you could only compile code every three weeks? It'd feel weird, right? Three weeks of compilation issues to be solved in one day. Quite dramatic day, full of havoc. Obviously, this is not a good idea. Luckilly, this is not the case - we have tools that basically recompiles our code all the time. We find issues as we write, we fix them and everything is fine.

What if i told you, that you could only test every three weeks? You write code for three weeks, and then you test and find that stuff you wrote a week ago doesn't work. TDD and testing approaches in general work well for these scenarios. We have realised for some time now, that we need to test more often.

So it works on your machine. Great! What about your customers' machines? What about on the server where it is supposed to run? This is what continuous delivery and continuous deployment is all about - we're not only checking that the code compiles and passes tests, it actually runs on a production like system. This should be done often. At least on a daily basis.

Automated Build: What to do
Continuos Integration: When to do it

Force: You want to start getting feedback from your customer as quickly as possible
Problem:Too many details, specs are foggy or changing over time
Solution: Shipping skeleton
- Start by releasing
- Deploy a hello world empty skeleton
- Then fill out the product
- Continue adding small build features as you go along

This enables quick demos without extra work. Going to remove a lot of stress on the project. This rhymes well with Feature Driven Development where you focus on shipping cross-layer features (vertical slices). Every day is demo day, every hour is demo hour. This makes demos almost boring - Continous Integration should be boring, not risky, scary and exciting.

Good mantra: "If you hate it, automate it".

You want to have a shipping skeleton.
You do not know where to start
Simplest toolchain (ask for this on the start - always ask).
- Build Machine (with team city) (+ agent machines (optional))
- Test Machine
- Staging Machine
- Production Machine

- This can all be done in the cloud (EC2 is wonderful).

Staging should look exactly like production (same deployment path (e.g. FTP)). However, in staging, you can install extra monitoring tools as long as the deployment path (including credentials) are the same.

You want to build a version from 1 month ago
Your CI Server is configured to run today's code structure, which is different than last month
Build Script Injection
- Allow version aware builds
- Build scripts are part of source control
- Build configurations on the CI server are dumb triggers

- The CI server doesn't need to know about the build - it just gets the build script at the root and invokes it.

You want to repeat the same scripts with different or targets
Your script has hard coded values, or the build env has hard coded env. variables
Fill in the Blanks
- Build Script uses placeholders for system related knowledge
- Placeholders are filled from environment variables or other types of parameters to the command line
- These variables are SET by the Build Configuration on The CI server

- Final Builder (tool) for Windows, rake for linux/unix.

Build Waves if your build takes a long time (CI on each checkin, deploy to test (triggered on successful execution), deployment to staging (manual), deployment to prod (manual)).

Produce artifacts: CI should produce binaries that the deploy to test can then deploy these; same with stage and production - same binaries, not binaries produced from the (potentially) same source code. You can configure this by using dependencies between builds.

Builds and Tests are made to be broken. Don't be afraid of breaking the build. Just make sure someone fix it.

Avoid tools that force you to directly edit XML. It's not productive.

What's a beautiful build?
- You can see flow
- Coherent: You can understand the structure


Strive to have builds that are easy to edit.

Comments

Post a Comment

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Image
TL;DR: Yes, they will. Thank you for your time. 😄 Background At Redgate, engineers enjoy a great benefit in that we get are expected to spend 10% of our time to improve on our craft.  Having suffered this week with manually having to copy a bunch of properties from a domain object to its HTTP representation, I decided to spend this week's 10% time to see if I could answer the following questions: Can use AutoMapper to simplify mapping between two types?  Does it also allow me to map between a regular type and a record type? What about the other way around? Can I use this to reduce the maintenance burden in my product? Mapping between two types [automapper fundamentals] To started and get a basic mapping done, created a .NET 5 ASP.NET Web API project, added the below package references and configured automapper : < PackageReference Include ="AutoMapper" Version ="10.1.1" /> < PackageReference Include ="AutoMapper.Extensions.Microsoft.DependencyInj
Read more

Unit testing your Azure functions - part 2: Queues and Blobs

In our last installment , we discovered how to start unit testing our Azure Functions, looking at the HTTP Trigger (and evaulating the function's HTTP response). This time, we'll take a look at using the QueueTrigger, getting supporting data from table storage and outputting Blobs. Yup, I'm tossing you into the deep end! What are we trying to accomplish? This time, we will test a function that performs some arbitrary business logic on bank accounts. The function responds to a storage queue request, logs each command and ensures that each received command is executed exactly once. Almost like a real-world function, huh? ;-) In the function above, we are introduced to three types that we need to deal with in our unit tests - the IQueryable interface, IAsyncCollector and the CloudBlockBlob concrete type. IQueryable is easy enough to work with: Introducing the Testable Async Collector When I first started exploring this topic, I figured I could just use my favourit
Read more

Testing WCF services with user credentials and binary endpoints

Image
This article discusses the following error messages that you might receive from a WCF service An error occurred when verifying security for the message HTTP/1.1 415 Cannot process the message because the content type 'application/soap+xml;charset=UTF-8;action="..."' was not the expected type 'application/soap+msbin1' When doing analysis work on existing services, invoking them in a safe test environment is a handy way of getting an understanding of their operations, especially if the documentation has gone missing (or was never written). SoapUI is a tool that can be used to test WCF Services, but did you know that Visual Studio also comes with its own set of tools? Let's start with SoapUI, which is available from  http://www.soapui.org/ . Its operations are quite straight-forward; however, you might run into issues when trying to access services that are protected by user credentials, or when accessing services with binary endpoints. I
Read more