I'm noticing a pattern and it has to do with the overloaded process of continuous integration. This has become a reference to executing tests on every commit. I'm not saying this isn't important.
I am seeing articles about long lived branches and trunk based development. These articles are all about continuous integration, but they can't reference this age old solution because it is no longer about integration.
Now that we understand trunk based development is just continuous integration for the git era of version control let me talk to you about micro services and sharing code through package managers.
The explanation behind them is that they help decoupling and independent development. But independent from what? These usually are consumed by software which may wish to work with multiple services together.
Are you the consumer of these service or providing them to others? It does not really matter your just building one part of an integrated system, as a provider you will still want continuous integration with your changes and as a consumer you don't want to get left behind on old deprecated APIs.
No matter how you organize your application don't forget the lessons which lead to continuous integration.
Top comments (2)
I'm having a hard time to understand what you are trying to convey.
Are you implying that CI is repo/app based and the move towards micro-services just brings back all the old problems of multiple branches?
If this is the case you need to be aware of the full scope of Continuous Integration.
It's meant to test the integration of the service into the ecosystem.
Let's take the following case, a change to one of the micro-services has broken its dependency in another one. Due to a change in the API the other service can no longer call the one we are working on.
This means that while individual tests will pass vs. a dummy service, once the code has been pushed and went live on an integration environment the test for that environment will fail.
There is no need to forget the lessons as it should be taken care of in the grander scheme of things.
Now, when you are talking about orgs who only pay lip-service to CI, well... ;)
I think you understand but yes, CI is repo based:
"Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day."
Now I'll try to use Jenkins as an example for context. With each release of Jenkins you have plugins built at different versions and used in many combinations of different plug-ins and load orders.
Now as a company you are the supplier and maintainer of the use of all those Jenkins instances. I am tasked with verification that an update to any component does not break the use of that component across all versions and combinations (used or to be used)
Now are you hitting CI you work on a plug-in and work off master, what about with a coworker? What if your plugins is tested in one of the Jenkins instances? What about all instances? All combinations of plugins?
Where does CI start? When have you gone beyond CI? It starts when there is collaboration starts, and ends when it hits production. This is why I'm trying to emphasize the larger implications of only meeting CI.
Personally I am targeting a base instance of Jenkins with a good set of default plugins which everyone works on and moves into their instance continuously. I do not need each plugins to trigger its integration with all instances.