What's your software deployment strategy?

Manual deployment is passe, but still can't be fully avoided, especially when a new project is initiated, it make sense to start with manual deployments in the earlier iterations before automating the process. It also works in unique deployment scenarios where automation is not very cost effective, but such cases are rare with the current set of tools that are available these days. The main disadvantage of manual deployment is that it is prone to human error(s), apart from the fact that it is not efficient in complex setup where there are so many stages before production deployment and cannot scale.

Software deployment process and techniques should be nimble. The design of the software should be such that the individual features can be deployed without affecting the whole solution. It is like customers and users should continue to use other features on the software when we are deploying upgrades to another feature. Adopting DevSecOps methodology for our deployment processes is one of the key aspects.

For a short-lived project, it's okay to use manual deployment with right controls. Else invest in continuous iterative automation.

For manual deployments create checklists. It's very cheap. You need a pen or pencil and paper. Write down what needs to happen during every deployment. Include items for pre and post deployment checks. As you solidify the list, type it up. Then, consider automation. Test. Test. Test. Yes manual deployments can be prone to human errors, but automated deployments can be prone to human errors as well. Computers are great at doing whatever we tell them. Including making the same mistakes over and over.

Software deployments is an important phase of SDLC and it is always critical. Since in manual deployments there is always a possibility of partial deployments of files or miss to deploy the entire release files on any of the server which directly impact the functionalities running on the production servers and impact the business users. There should always be a backup plan ready before deployment to make sure if there will be any issue post deployment then it can be easily rolled back and make all the production systems up and running with very minimal downtime.

To get the full benefit of automated deployment, we can improve the quality of the deployment's artifact by adding steps to run unit or integration tests. Even if it prolongs the duration of the process, you can detect those bugs early or prevent regression.

Understand the end-to-end nature of deployment. Invent and simply the steps for manual deployment. Build the right controls, monitoring and reporting. Continuous iterative automation to improve developer experience and operations team productivity.

Deployments means going live. Automated deployment is a must to scale up for following reasons: 1. Does dependency checks, simulations before deployments and have easy roll roll back options most of the times. 2. Go live is critical due to size of the project being medium to large and a lot of objects. 3. Useful if heterogeneous environments but not a lot of deployers can do, this in a complex environment. 4. Also gives great control over every objects and needs lesser skills than manual deployments. 5. Human cost is less versus tool cost, but mostly comes built in ERP systems. Bottom line is size of the project drives manual versus automated deployment.

Automated deployment are built on manual deployments. The tool(s) you select for automated deployments but you are choosing those challenges with an idea on how to work through them. They are necessary for optimizing your SDLC CI/CD process. You are work through code faster and reduce the time to client.

Any deployment can be automated! If you are building a new product, then you can easily, quickly, and cheaply create automation from the start. Growing the complexity of the automation as you go. Automation is the difference between fast and high quality releases, and slow poor quality ones. If you already have a significant product that does not have automation, then there would be significant investment in improving the quality and consistency to a point where you can automate everything.

If your continuous deployment pipeline is exposing your end users to untested or unstable software then your level of product quality is too low! Fix that!

One of the things not discussed when talking about CD is "courage to deploy". If your engineers feel like your deployed application is a wobbly Jenga tower, they're not going to want to be the person that collapses it by pushing new code to production. This fear is probably more dangerous to engineering teams than anyone realizes. CD requires strong automated testing, good monitoring, and it releases your engineers to make mistakes. If you have the right processes and standards in place, your engineering staff will release with confidence -- and that's invaluable for developer happiness. Lastly, the fear of deployment can lead to larger releases where it's hard to pinpoint what might have gone wrong if anything did.

Phased or pilot approach is not CD. CD is a state where you trust the developers and the testers to build mature solutions. The pipelines and tests are built in advance and live along with the code being developed, merged into protected branches. If it isn’t handled by mature developers then the PR review process is stressed out!

CI/CD starts with pre-prod. You never turn on a prod CI/CD without rigorous pre-prod testing. That said, CI/CD helps you turn code around faster. Add in Unit testing, loading testing and you'll reduce bugs in production.

Recently I rolled out a process/tool at the company level and used the Rolling Deployment or Phased Rollout model. With this strategy, we deployed the software to a small group of users at a time, and then rolling it out to more users in stages. This actually helped us to identify and address issues early on, while also allowing us to have a more gradual transition. With this approach we were able to attain reduced risk, improved end user experience and more efficient use of engineering resources. The flexibility we received due to the phased rollout plan and the comms strategy we put in place to keep the users apprised on the change management approach helped us in this rollout.

The choice of my deployment is based on what scale the app is expected to perform. It could be simple git push or automated GitHub Actions. But the paramount is: monitoring the deployment process before, during, and after. Before: - checklists - feature flags - release candidates - revert procedures During - status - logs - alerts After - testing - monitoring - scaling - documentation - notification

In my view, automated deployment strategy is going to be an iterative one. Focus on readability, maintainability, testability and traceability of the deployment and goal should be that the outcome should be stable. start with the easiest and less error prone one to start with and incrementally add features to cover the full deployment cycle.

The choice of development strategy for a software product should be defined according to the ability of a new team, and during development, the development strategy should be expanded and approach the usual standards, so that the team matures.

The traditional approach to application deployment involves redeploying an older version in case of failures, which can lead to extended downtime. Blue-green deployment addresses these challenges. It creates two identical environments: the blue for the current version and the green for the new one. This enables seamless testing and validation without impacting the live system. This approach boosts application availability, simplifies rollbacks, and ensures a safety net in case of deployment issues.

The purpose of a deployment is to make a software available to the intended users- Developers (Dev)/Testers (SIT)/Business Users (UAT)/External Users (Prd) To help chose an appropriate deployment strategy, depending on the business priorities it should define: - What: Deploy the packaged code / configure based on the env / post deployment testing (Functional & Non-Functional) / notifications / rollback if required - When: Scheduled / On-demand / Dependent on the previous step of the pipeline - Where: Dev/Test/Prod; Primary/DR; Partial (canary)/Complete - How: Maturity of the process, availability of resources, technology know-how. Could be Manual, Automated or a Hybrid approach, considering the pros and cons discussed in the above sections

It is always beneficial to have IaC (infra as code) scripts and have production-like lower environment spin up as required to validate the change(s) before it gets to production system, it makes sense to invest in continual upgrade of deployment automation and make the CI/CD/CT as robust as possible with repeatable process for creating new environments that are as close to production environment.

Another angle to consider is whether to develop the software at all. The cost of the software doesn't stop at deployment to production. The ongoing maintenance, support, and enhancement is something that organizations should consider as the total cost of ownership. I'm of the opinion that unless there's nothing in the market that can fit 80+% of your needs or the capability IS your competitive advantage. You should acquire instead of build. So, another deployment strategy is to not build at all.

Deployments is one of the 1st thing to manage and not the last. Please do not take short cuts with deployments and deployers lot of freeware tools and less expensive tools available. Keep in mind: 1. Project define - dependency check. 2. Project compile and build - dependency check. 3. Project mapping where all to be deployment - dependency check. 4. Project Simulate and deploy with roll back options - runtime dependency check. Make sure you know how to roll back. Verify deployments are successful, sometimes tools go wrong they are designed by humans.

Whichever deployment strategy you choose should be utilized across as many layers of your environments as possible. At the very least the layer just before production, whether it be staging, testing, or whatever name you give it should utilize the same deployment strategy and toolset as your production layer.

Choosing the right deployment strategy for a project or startup depends on factors like complexity, investments, and strategy. Continuous deployment can save time when automated quality checks are established in lower environments for new features before customer rollout (which in turn is pushing to main).