When finding yourself developing different applications in the same domain you will most likely come across the need for using the same functionality that have already been implemented in another application. However, in a project with many different applications, code repositories, microservices and developers, it is not by any means straight forward to adopt a flexible and efficient code-sharing strategy. In Fortum Oslo Varme (where I operate as tech lead) we have a code-sharing policy of always building reusable code-packages for functionality that are needed by more than one component. This way, it is easy to have control over where the code is located, improve maintainability, reduce errors and the time spent coding, and make it easier to push new features and fixes to all components using the same functionality. We have our own private code registries for our .NET Core and Angular code packages, meaning that we have one NuGet registry and one NPM registry.

Let us start having a look at the overview of our code-sharing platform in the figure below:

code-sharing strategy

Development and release process

All code-packages are placed in their own code repositories (if several packages are tightly coupled they can be placed in the same repository), and during development all packages have a «beta» suffix in their version number. The beta-suffix is there because most code-package management systems support wildcard references to code-packages, meaning that you can for instance declare your code-package dependency as «1.0.*», and you will get the newest beta package for version «1.0.0» every time you restore your dependencies. The beta-suffix is there to make sure that there are no breaking changes in our code-packages during development, as this will then be discovered in our nightly continuous integration builds where all application components are restored, built and tested. With the beta-suffix we always make sure that the newest code-packages are valid and do not break existing functionality.

When new functionality is merged to our «develop» branch in the GIT repository for the code-packages, we have automated scheduled building and publishing of the code-packages to our code registries, meaning that the new beta packages are always published immediately after a new feature has been merged into the «develop» branch. For final releases, we always do a manual package-publish of our new release-tag in the repository into our code registries.

When an application is ready for release to production, we always make final releases of the code-packages that this application is dependent on, and update the dependencies to these packages to their final release versions, e.g. «1.0.0» instead of the previous beta-reference «1.0.*».

Naming conventions

All our code-package names are starting with our domain name followed by the application the code-package belongs to, and finally the name of the functionality in the package. An example of such a package is «Heating.CustomerPortal.Domain», which is the reusable functionality of performing operations on our service layer communicating with the database of our customer portal. We also have shared code-packages that are applicable across our different applications, for instance «Heating.Shared.Utilities», which is our shared utils library.

In the next blog post, I will give a concrete example of how you can build and publish your own NPM packages in no time.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *