Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Data junkies rejoice, this is the episode for you.
On this week’s episode of Dev Interrupted, Einat Orr, co-founder and CEO of Treeverse, sits down with us to talk about the state of data… where it’s been, where it’s going and why having bad data might be worse than having no data at all.
We rely on Docker, and it’s one of our favorite technologies. But using Docker for commercial software shows some rough edges that we found the hard way.
It seems like the “latest” tag should work, but it really doesn’t, except in the simplest cases. We didn’t realize how crazy broken this could be until one night we were on a Zoom call and watched a new customer install software that was three months old, when there were 10 newer builds available. Not a good feeling.
It is crucial that each piece of code you deploy have a unique version, it helps you track what your client is running, mark deployments with breaking changes, and makes your life so much easier — especially when trying to understand what changes are running at your client site in the middle of the night.
When you develop microservices, it is twice as important. Usually, you deploy your services individually and you need to know which version of which dependency is used by your service. Another requirement many developers face is how to automatically (or manually) update your dependencies when they change.
More than 60% of enterprises are adopting a microservices architecture (MSA), yet they often fail at designing, building, and managing it. Implementing a successful MSA is more complex than monolithic application architectures, as it demands more discipline and effort on the part of IT professionals. Remember moving from a monolith architecture to a microservices architecture is a key task in building an application architecture distributed globally and being a challenging task, brings inevitable backfires. You require a versioning strategy for interfaces and services.
In the words of Gary Olliffe, Research Vice President of Gartner, “The superpowers of MSA can, in large part, be attributed to the benefits of loose coupling and decomposing systems into component services that can be developed, deployed, and operated independently of each other.” Having said that, technical professionals need to stay focused on loose coupling systems and thus make design decisions to accomplish their MSA goals.
After the gang of four (GOF) Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published the book, Design Patterns: Elements of Reusable Object-Oriented Software, learning how to describe problems and solutions became popular in almost every field in software development. Likewise, learning to describe don’ts and anti-pattern became equally as popular.
In publications that discussed these concepts, we find helpful recommendations for software design, project management, configuration management, and much more. In this article, I will share my ideas about version numbers for software artifacts.
One of the challenges I have seen teams struggle with nowadays is versioning their packages. One of the problems with adopting any versioning system is that typically you have to version (at least) two components: the binary you are releasing AND the source code at the time you have built the software. Doing this allows you to easily match versions in production to the source code — which needless to say, makes it so much easier to diagnose things.
You may also like: Welcoming the New Era of Java
In the Java world, this becomes an even more interesting problem as the binary can be versioned based on a naming convention ( package-1.2.3.jar) as well as via the manifest file. Luckily, there are a lot of plugins that can help you with versioning the jar filename — and equally, it's pretty easy nowadays to generate a manifest at build time that contains the same information.
In this article, we are going to look at how to implement a multi-module project in Maven with versioning and dependency management, as well as the best practices for building big, large-scale projects from both a developer perspective and a DevOps/management perspective.
However, if you are not familiar with Maven, I highly recommend reading this article first and getting some experience using Maven. This article will not cover Maven basics.
A few weeks ago, Weaveworks and Snyk delivered a webinar, entitled, "Secure GitOps pipelines for Kubernetes." The theme of the webinar was on how to improve the security of your development workflows — from Git to production.
Brice Fernandes, Customer Success Engineer at Weaveworks kicked off the talks with an in-depth look on what GitOps is and how it improves the overall security of your CICD pipelines.
In some ways, version numbering schemes can be a lot like TABs vs. Spaces or emacs vs. vi. You know the kind of wars where the wrong people just keep on fighting even if TABs are evil and emacs is harder to quit than vi? What interests me, however, is that often, there are really rather interesting reasons behind the choice of one version numbering scheme over another. In that context,I thought it might be interesting to share with you our reasons for selecting the version numbering scheme we use internally for the CloudBees DevOptics components.
If reading a post is not your thing, you might be interested in this video I recorded on the same topic:
Life is subdued to constant evolution. So is our data, be it in research, business or personal information management. As such it’s surprising that databases usually just keep the current state. With the advent, however of flash drives as for instance SSDs, which are much faster in randomly accessing data in stark contrast to spinning disks and not very good at erasing or overriding data, we are now capable of developing clever versioning algorithms and storage systems to keep past states while not impeding efficiency/performance. Search/insertion/deletion-operations should therefore be in logarithmic time (O(log(n)), to compete with commonly used index structures.
Sirix is a versioned, temporal storage system, which is log-structured at its very core.
We support N read-only transactions, which are bound to a single revision (each transaction might be started on any past revision) concurrently to one write transaction on a single resource. Our system thus is based on snapshot isolation. The write-transaction can revert the most recent revision to any past revision. Changes to this past revision can then be commit to create a new snapshot and therefore a new revision.
The most effective development processes are tailored to the company and product IT teams are working with. The most effective teams develop standardized processes that help reduce errors and speed up the software delivery lifecycle while increasing efficiency for their specific product.
DevOps spans people, process, and technology, and can be integrated into every IT team. Combined with best practices for each team’s technical landscape, it can create more efficient processes that deliver high-quality software to market in less time.
Versioning is the act of assigning a label to a software package (whatever from a single file to a complex application). You surely are used the Maven version scheme, and maybe heard about Semantic Versioning . But anything that labels software units in order can be understood as versioning: Timestamps, Commit ID trees, or just numbers or strings.
One may question the need for versioning. If you only need the latest “state” for your product, you are right, you don’t need versioning at all. Sadly, you will be missing a lot of interesting capabilities: