In 2006, Martin Fowler posted his now famous essay on Continuous
Integration. Looking back, what seemed revolutionary, radical or just plain
crazy is now common, pedestrian and "just what you do." I love it.
Back then, building and releasing software was a real pain. Integration was
something you did at the end, after code complete, and we didn't know how
long it would take. Some people may recall how we, as an industry, spent a
massive amount of time integrating code from one team with another, or even
just between developers that sat next to each other. The arguments against it
at the time seemed valid and impactful. Now they seem weak and silly.
Fowler proposed Continuous Integration, an idea that was simple, elegant and
had far-reaching repercussions. By producing constant, automated,
self-testing builds in development, a huge amount of resource overhead
Why Customers Choose Datical DB to Automate Database Deployments
Over the past year, Datical has had amazing success with our flagship
product, Datical DB. We've seen multiple visionary, sector-leading
companies select Datical DB to drive their Application Schema changes. Now
that the number has grown rapidly over the past year, we can begin to see
patterns in why customers choose Datical DB.
One of them turns out to be pretty emblematic of our other customers. So,
let's examine the reasons why they chose to adopt Datical DB.
Customer Facing Applications Are the Front Door
When ... (more)
Microservices architecture enables flexible architecture and speeds up your
development process. But, often people are confused as to where to start.
The obvious choice is to use a microservice architecture for all new
applications. However, you have a ton of time and money invested in legacy
applications. Applications that handle your user authentication and access to
your company's core products and services should be rewritten. You should
definitely leverage those legacy applications to get to microservices faster.
And, you can do it without changing your existing Database ... (more)