Continuous Deployment Considerations in Architecting Software Systems

This post discusses how to make Continuous Deployment easier by taking it into account during the design process.

When architecting a software solution, there are a lot of decisions to be made. Critical areas such as:

• Maintainability
• Availability
• Scalability
• Flexibility
• Security
• Performance
• Internationalization
• Cost
• Time…

 

Software Architecture is a balance of tradeoffs, frequently influenced by the key factors at play during the design. In fact, many software systems are not architected. They just grew from a simple start and evolved without planning.

One area that is often overlooked in the design is Continuous Deployment. It’s not intentional, it’s just that the activities associated with Continuous Deployment and Continuous Integration is usually an afterthought. Those types of activities are not as exciting to most engineers or architects and so they are left for last.

So the question is, why wouldn’t we want to Continuous Deployment to automate those mundane, boring, repetitive, risky tasks that everybody hates and that are a waste of your best talent? Often the answer is because it’s hard to overcome the challenges as a result of a lack of planning or no planning at all.

But…

What if with just a little extra effort, you could make your life or someone else’s life easier in the future? What if you could take a step toward automating and routinely measuring some of the very considerations in your design? After all, we don’t just architect a solution and stop improving it. We must measure and adjust constantly as the system evolves.

Continuous Deployment and Automation simply must be considered when selecting a given technology, application, or component for use in a software system. The selection of a product or technology that is difficult or time consuming to deploy is a costly decision. The wrong decision can doom the deployment process to the manual efforts of a team. This will only serve to increase cost and frustration as you spend your weekends and nights wrestling with the complexity. So why not employ a simple rule of asking and verifying the questions: Can it be scripted? Is there an API?

Remember that projects grow. Even very small projects can become quite large, so consideration of the patterns and practices used for larger projects should be included from the beginning. In fact, make it a standard that every type of project starts with the same structure, services and frameworks automatically. How? Scripting.

Some Other Continuous Deployment Considerations

• Do your environments need to be manually configured either at deployment or initial setup? This includes things like connection pool settings that need to be set or be the same across clusters.
• Is there any third party software on which the application relies?
• Are there any third party components that require manual installation, configuration, or some other dependency?
• How is the database deployed or set up and is there any data that is required?
• Do you have all of the data that the application may rely on and is it scripted?
• Is there anything that relies on the system registry?
• Do you have permissions for file access that need to be setup?
• What services are required and what level of access do they need?
• What is the cost of remote calls from your application to other applications, or services when working with distributed systems? This cost is often lower when testing locally.
• What about your code’s project structure and organization in source control? Is it organized so the dependencies between them will allow automatic builds for Continuous Integration?
• Consider any software, configurations, or other components that must be manually configured or deployed. Research if the setup, deployment, and configuration can be scripted/automated. If not, this should be strongly considered as a major priority.

The considerations above are included here because they are often some of the common pitfalls and challenges that are faced by software teams who are looking to implement Continuous Integration, Continuous Delivery and Continuous Deployment.

The Point

The point of this post is to inspire some heroes who will take this to heart and build this into their design habits. This is because these are the heroes who will pave the future for their company and avoid subjecting all those who come after with the painful path of overcoming the lack of planning of the past.

These challenges always seem to trigger the statement: If only we had thought about that years ago. The hero can change the statement to: Thank you to whoever set this up. And the heroes’ reward will be more time for their fellow IT brothers and sisters to spend with their family on weekends and nights.

Continuous Deployment Considerations in Architecting Software Systems

You may also be interested in: Continuous Integration vs. Continuous Delivery- What’s the Difference

Third Wave is a boutique software development company located in Boca Raton, Florida. Our business acumen, agile development solutions, and perfected continuous development process offer unmatched levels of expertly crafted software and development services. Our team is dedicated to helping companies break into the new era of rapidly changing business trends with adaptive technology that provides sophisticated business solutions.

Third Wave also offers Cloud CDE, a fully automated cloud based Continuous Delivery Environment “in a box”. Cloud CDE and our consulting services provide a jump start to organizations that are ready to start transforming their culture to a high performing IT organization.