An Enabling CI system
My two cents on CI, One of the important features for agile continuously delivered microservice is a lean process both in engineering and in systems. The CI system is critical to it. Abilities like
- Self-contained build specification
- Simple specification
- Good community support and references
- No hassle of managing agents
- Easy to onboard
immensely simplify and let the developers concentrate on delivering the working software. And Travis CI fits this bill, very well.
A BRIEF ON WHAT IS SELF-CONTAINED BUILD SPECIFICATION
If you can mention all about a built process in just one place, one file and include it along with the code in the same repository, in a convenient specification, how awesome is it? That is exactly the Travis yml file.
Of course there are other build systems like CircleCI, Codeship, AppVeyor (for Windows) etc that take the similar route.
DISADVANTAGE OF HAVING BUILD SCRIPTS SCATTERED
Traditional build systems have this problem, where part of the scripts required for build-deploy pipeline gets included along with the code repository, while the agent and process intelligence or knowlege of have the rest of them.
The scattered nature of such build process itself impedes the transparency and simplicity of a build process. This worked fine when the development team need not have to bother about deployment. This even worked when we need to deploy regularly but had an expert and his time to get this correct. But, do we need need to depend on a expert every time? espcially with a microservice architecture, where new services come up every day? I say no.
LIMITATIONS WITH TRAVIS CI AND MY TAKE ON IT,
Cannot build windows based .NET code
This is only a limitation for time being, till we all move on to platform agnostic dotnet frameworks.
Cannot pipe the build process
This one came up several times when deciding on CI system. However for the last one year, I haven’t heard anyone asking for it.
In my opinion, pipelining builds represent a coupling, they smell one of the below,
Either domain boundaries are incorrect, so we have to queue builds to get one functionality out
The repository boundaries are incorrect, so we have to get more than repo built to get a functionality out.
Simply, the services aren’t designed to be backward compatabile (blinks PACT)
Only limited agents
If a build is taking less than 5 mins including deployment, Do you think the availability of agent will block you? I bet not. We have been living with 2 concurrent jobs / agents for almost one year. We currently have around 15 active repositories using Travis CI and haven’t heard a blocking build situation.
After all, when it is getting blocked, we can simply shell some money and get more concurrent jobs.
What is your CI story?
Is something not working in your microservice story?
What causes the most frustration in your CI process?