Interlok 3.9.3 has been released and is now available for download.
Interlok is a bit like pick'n'mix; I prefer fizzy cola bottles, maybe you like flying saucers
We pride ourselves on not having too much of an opinion about whether or not you should write code, or use configuration to achieve your integration. If you have, by instinct, a developer mindset then you’ll naturally gravitate towards writing code because that’s what you’re most familiar with. This is something that we get quite a lot from new customers where their technical team are primarily developers. I can do this in language X; but I can’t in Interlok; why should we bother using it. That’s one way of looking at it; we prefer to look at it in terms of what does Interlok give us that means we can spend more time on providing business value. …
Interlok configuration probably isn't Turing complete; but we can write code in XML...
We’re busy migrating away from Bitbucket; not because there’s anything wrong with it; but because as an organisation that’s grown out of 6+ companies, you have to rationalise and standardise things like source control; we’re using GitHub, Bitbucket, multiple on-premise Gitlab instances, Azure TFS; you get the picture. Apparently we need a spreadsheet (it’s always a spreadsheet) of all the projects that are currently in Bitbucket and when they were last used. That’s right; it’s time. …
Import our build parent to simplify your build.gradle
We’ve standardised on gradle as our build tool of choice when developing solutions with Interlok. Since it’s possible to end up down a rabbit warren of scripting with gradle; maintaining the build script is one of key considerations, while also providing what we consider best practise when working with Interlok. As a result, we have an early preview release of our proposed parent gradle file that you can start using when developing Interlok based projects. …
Early notice about things that might break your deployments in 3.10
3.9.2 was internally named Replacement Killers and the next release currently in development also has a similarly themed name; we had a thing for Chow Yun Fat films this year… This next release is intended to be the last release in the 3.9 series, and 3.10.0 may break some existing deployments. …
You can cut and paste old config; but you probably should investigate new features
One of the things that happen when you start using Interlok for any length of time is that you end up copying old configuration, templated or otherwise; it works, there aren’t any deprecation warnings, and it gets the job done. In some cases, what we might have done previously is different to how we’d approach the problem now. A case in point is the building up of complex metadata values. …
Interlok 3.9.2 has been released and is now available for download.
A collection of services that provide PGP encryption, decryption, signing, and verification.
Interlok PGP is a collection of services that provide an easy way to perform the major PGP functions: encryption, decryption, signing, and signature verification. It uses Bouncy Castle to do the heavy lifting. …
Dynamic services have changed; plus ça change, plus c'est la même chose
In 3.8.4 we deprecated
dynamic-service-locator; this decision wasn’t taken lightly, but change and evolution is necessary so that you can get where you want to go. Originally
dynamic-service-locatorcame about so that people could make changes to configuration independently of restarting. It was only really useful if your possible configurations didn’t require new components (e.g. you always dealt in XML, and never used JSON). In fact a lot of the time it was abused by people logging to the production system and modifying config directly which wasn’t nice. Even though it’s deprecated; changing the service chain that you execute based on various things at runtime is still possible within Interlok. …
Mocking AWS interactions with localstack
One of the habits that most of our team have is to try and run everything on their local machine as much as possible to test behaviour and logic before doing any kind of deployment to something that isn’t directly within our control. It’s habit more than anything, coupled with the fact that we often do a lot of work while we’re not connected to the internet. Virtualisation, and container technologies like Docker are our best friends. …