Four Best Practices of CI Builds

Continuous integration builds (also called CI builds) are an absolute process game-changer, turning a local ‘works on my box’ coding and deployment strategy into an automatic and reliable process. Once a team gets a taste of an automated and reliable build process, it is easy to fall into a trap of adding all of the things to your CI build. Integration tests, security scans, performance tests, etc, until eventually, the CI build has lost the features that make a CI build implicitly valuable. The best development teams keep continuous integration builds simple.

Best Practice: With no changes to code or steps, the result of CI builds should be the same.

Responsibilities of the CI Build

A CI build’s job is to collect all developer changes, and create a releasable artifact, ensuring changes from all developers on a project are included in the product, and don’t cause conflicts with each other. A CI build must be fast, so that changes that break a build can be immediately corrected; a quick feedback loop is essential to the CI process. A CI build should perform the following steps:

  1. Collect all source code and changes.
  2. Restore dependencies.
  3. Compile / construct the build.
  4. Run unit tests and build verification tests.
  5. Create the artifact.

Assuming the same code input from step one, and no changes to any of the steps, a CI build’s result should be the same, every time.

A new CI build should be executed if the state of any of the five items above are modified. If there’s a code change anywhere, step one has changed. If any dependencies are updated, in the framework or libraries the product uses, step two has changed. If a build setting has changed, like going from 32 bit to 64 bit, or from ‘debug’ mode to ‘release’ mode, that is step three. Unit test changes typically are manifested as code changes, but any test settings changed would be an item for step four. If the artifact construction process changes at all, that’s step five.

Best Practice: Execute a new build on any individual change to those steps.

Tempting Steps You Should Avoid in CI Builds

  • Code Security Checks
  • Integration Tests

Code security checks are tempting items to add to a CI build, but fail the ‘no changes to code or steps’ rule. Most code security checks are rule-based in nature, getting updates when there is a new known vulnerability. The process is similar to a malware database updates. With no code change, and no change to steps, but an invisible-to-the-developer modification to the security changes, builds can succeed or fail seemingly randomly. Also, the scope of secure code changes can be larger than common unit / build verification failures. A security change can be very small, but more commonly is larger and design-related.

Best practice: Include code security checks on a regular schedule, not directly connected to the CI build, and have those check failures create backlog items the developers can research and correct.

Integration tests are tempting to add to a CI build, but fail the rule of failing fast. Any system large enough to have integration tests in the first place will be a fairly complex set of tests to run, which may take quite a while to execute fully. They also tend to rely on a lot of scripting and setup work.

Best practice: Include integration tests as a post-CI step in an automated pipeline separate from the CI build.


To recap: Continuous Integration builds should be quick, automated, and provide a fast feedback loop. They should contain the following steps.

  1. Collect all source code and changes from the repo.
  2. Restore any dependencies.
  3. Compile / construct the build.
  4. Execute Unit Tests and Build Verification tests.
  5. Create the artifact.

Remember the best practices of good CI builds:

  1. With no changes to code or steps, the result of CI builds should be the same.
  2. Execute a new CI Build on any changes to the five steps.
  3. Include code security checks on a regular schedule, not directly connected to the CI build, and have those check failures create backlog items the developers can research and correct.
  4. Include integration tests as a post-CI step in an automated pipeline separate from the CI build.

Happy building!

Six Questions You Need To Answer When Learning a New Programming Language

Are you someone who wants (or maybe is being forced) to learn a programming language? Learning to program isn’t just syntax and structure. Here are six questions you should answer about your programming language before writing your first program.

While learning the syntax, structure and tools, make sure you can answer the these questions.

1. What is latest version of your language?

By keeping yourself with the most up-to-date versions of your language, you minimize the risk associated with using old software with known security flaws. Building software can be risky, if not done carefully, so make sure you are using the most up to date version of your language.

Paying attention to the version information is also a great way to date the information and numerous resources you find out there in the wild. C# is in version 8 now. If you find a book about C# 2, it is NOT new, and can probably be recycled.

2. Who hosts the documentation, and where?

Programming languages will either have an organization, or a corporation which acts as the owner / maintainer of that language. C# is owned and maintained by Microsoft, and the C# documentation is hosted on their website. Python is hosted by the Python Software Foundation. Java, by Oracle.

Find the documentation website, and favorite it.

3. How do you manage dependencies and libraries?

Nowadays, nobody codes anything entirely by themselves. All languages start with a basic platform library that contains the very basic commands, keywords and structural expectations. C# has the .NET runtime. Java, the JDK. Often times open-source community provides the rest via a packaging system.

Learn your packaging platform, and how it works. Each package will often be just like the programming language itself, with versioning, docs, etc.

4. How do you test your code?

Unit testing has been a best practice for software development since the early 2000s. Unit tests are an extremely useful tool in your belt, enabling you to prove out functionality you are exploring or have written yourself. Every major language will have a library associated with writing unit tests. Using the packaging platform from step three, your next step should be finding out how to test your code. You, and your users, will be grateful that you did.

5. What risks are there? What should you watch out for?

In general, programming is a ‘high access’ activity on your computer, your networked environment, your data, etc. The convenience of doing things quickly or in bulk is precisely what a programming language can enable, so be careful. Make sure your SQL statements have WHERE clauses, and are guarded by a transaction that can be rolled back, if done in error. Make sure your loops have defined end states. Make sure you know precisely what your memory pointer is pointing to. Low-level compiled languages have more potential to damage computers directly by overwriting memory or restricted data. High-level interpreted languages tend to cause file or data related issues.

A computer does EXACTLY what it is told to do, and nothing more. Remember that, and be VERY sure it is doing what you intend.

6. How do you package and deploy the code you write?

Remember that code is just part of the story here, and is largely just a work product to the end result itself. Hosting a JavaScript site on a localhost isn’t enough, nor is a bunch of class files for a JAR file. When you write code, the goal is to ship an artifact of some kind. Don’t just start with Hello World, but start with Hello World deployed somewhere!


There are lots of resources out there for learning programming in a digital age. As you go through your learning, make sure you can answer these six questions while you’re learning the basics of the language. Happy coding!

Managing Expectations

Non-F# content warning: Skip to the next one if you’re not interested in general stuff.

Generally, a working programmer doesn’t have too many difficult “non-programming” tasks. Difficulty is the name of our game, and we like it that way. That said, one of the most critical skills a developer has is to manage folks’ expectations of you. Thought-work, in general requires a level of communication that seems nonstandard and maybe a little unnatural to your work.

The reality of being a working programmer is this: Your boss probably doesn’t exactly understand what you’re doing. Your boss may be relying on you to do a good job, regardless of his/her detailed understanding of your work. Making sure those expectations are set properly is key to keeping this relationship copacetic.

An Example: A customer asks you to sneak in a quick feature. You’ve taken a swag at it, and it looks like it won’t take more than a few hours and doesn’t impact anything, so you agree. Your customer leaves you happy, and everything seems fine. Fast forward to a week from now. The feature you were supposed to be working is late, and blocking everything going out. Your customer, who felt like his request was tiny, and shouldn’t impact anything, complains to your boss that the feature is late. Your boss, who has no idea that you agreed to anything, has now the unpleasant task of defending why the feature is late, even though she/he didn’t know it was part of the release. That makes her/him look disorganized and incompetent, and that’s not how you want to make your boss feel or look, even if you hate her/him.

Take a look at your day to day interactions and communications. Do folks know what you are doing? Do they know when you releasing your work?

Here’s a tip. Don’t assume that folks are reading every email, or “making the connection.” Make yourself very clear about what you are doing, when you expect to be complete, and if there are any items blocking you. If you are not sure yourself what to be doing, there is a very good chance you have not managed expectations well.