Git has become the ubiquitous source code management since its introduction in 2005. Along the way, a number of branching strategies (“workflows”) have evolved. As with anything in software architecture, there is no one right way to do anything; it all depends on context. In this post I’ll describe three common workflows to help you choose the simplest Git workflow for your team.
As a software development team grows and adds more members, what worked with one or two people no longer works as effectively. The team realizes they need to set up some sort of standard process for developing software. It need not be complicated, just a lightweight process will do. All they need is a way to get organized with a simple development approach. Here is what has worked well for my teams. Adapt it according to your team’s circumstances.
The other day I read a Pluralsight article titled Leadership guide: Your first 60 days as a CIO (registration required), and it made me think. While relationships are a big deal for CIOs, they also matter for everyone in IT. They matter to varying degrees based on your job role; nevertheless who you know and how well you know them makes a difference in your job and your career. Here is why I think in your career or your business, the further you go, the more those relationships matter.
Application deployments have usually meant deploying a new version of an artifact to Production, with stops along the way in Test, Staging, etc. All the new features and bug fixes become active when you deploy this new version. Although you’ve thoroughly tested the application with automated unit tests, functional tests, load tests, and performance tests, you’ve only reduced the risk of something going wrong in Production. If and when something does go wrong, you may need to rollback to the previous version. But what if the fix wasn’t as dramatic as a rollback? What if you could revert the one mis-behaving feature? Even better, what if you could select which features to activate? In this article I’ll explain how you can control your deployments with feature flags.
Suppose your client or your employer comes to you and says “We need you to help us understand how to set up a continuous delivery pipeline.” They assure you they are committed to the goals and benefits of Continuous Delivery, also known as Continuous Integration/Continuous Deployment (CI/CD):
- The software development teams want to reduce deployment risk.
- They like the idea of frequent small deployments during the workday instead of huge deployments once or twice a year.
- Teams no longer want to dedicate a full weekend to a massive deployment, with all the attendant stresses and risks that brings.
- The business is less tolerant of waiting months before they see even the smallest change; they want a faster time to market.
They have acquired all the tooling, and all they need is your guidance and leadership for how to set up a continuous delivery pipeline.
How would you approach this? What sequence of steps or phases would you use? In this article I’ll present some of my thoughts and suggestions.
History of Representational State Transfer
Roy Fielding coined the term Representational State Transfer (REST) in his 2000 doctoral thesis Architectural Styles and the Design of Network-based Software Architectures. In essence, he argues an API should use the existing HTTP verbs, and it should focus on representations of business objects rather than backend implementations. An example might be to model a Customer object the way the business knows and interacts with it rather than how it’s stored on the customer database table. In this post I’ll describe how to design an effective REST API using some of the concepts Fielding pioneered.
Most software development teams have one person with the role of Architect. Small teams of one or two people may not, but someone is thinking about architecture. This person’s title may be Solution Architect, Application Architect, Data Architect or Systems Architect. For now let’s consider all of them under the collective name of Software Architect. In this article I’ll talk about the characteristics of a good architect, and I’ll explain what a software architect does. I’ll also address the evolution of the role of software architect, and where it is today. By the end I hope you’ll have an answer to the question “so what does a software architect do anyway?”
What is it?
The pipeline architecture is one of the most common architecture styles used in designing software systems. Also known as pipes and filters, it consists of a series of discrete steps performed in a predictable sequence. This is different from the model-view-controller pattern in a layered architecture. In this article I’ll define what it is and when to use the pipeline architecture style.
So it’s time to move one of your legacy web applications from your on-premise data centre to a public cloud provider such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). This may be a decision you made, or one that your leadership team made. In this post I’ll explain what you need to think about when figuring out how to migrate your web application to the cloud.
This post explains how you can secure your Micronaut app with FreshBooks. Using FreshBooks’ OAuth 2.0 implementation, I’ll show you how to use the Authorization Code grant to authenticate with FreshBooks.
FreshBooks is an invoice and accounting Software-as-a-Service (SaaS) for small business.