# How to Deploy to Production 100 Times a Day (CI/CD) > Trunk-based development, feature flags, continuous integration, and a culture of trust: the building blocks XALT uses to ship to production frequently and safely. Source: https://www.xalt.de/en/blog/how-to-deploy-to-production-100-times-a-day-ci-cd/ TEAM XALT Atlassian Platinum Partner · 26 September 2022 · 9 min The success of a software company depends on its ability to deliver new features, fix bugs, and improve code and infrastructure in a short amount of time. Table of Contents show - Continuous deployment of small changes - Our development (and company) culture - Risk minimisation in a DevOps culture - Summary A short feedback loop is essential as it enables constant and rapid iteration. This requires the codebase to always be in a deployable state so that new features can be quickly moved to production. Achieving this can be difficult, as there are many working parts, and it is easy to introduce new bugs when delivering code changes. Small changes may not seem to affect the state of the software in the short term, but can have a significant impact in the long run. If small software companies want to be successful, they must act quickly. As they grow, they become slower, and then things get tricky. Now, - they need to coordinate their work better and - communicate more. - more people are working on the same codebase. This makes it harder to keep track of everything that is happening. That is why it is important to have a team that takes care of releasing code changes. This team should be as small and efficient as possible so that it can react quickly to code changes. Also use feature flags to switch new features on and off in production. This enables quick and easy experimentation and the possibility to roll back changes if needed. Set up alerts to notify the team when you introduce new code. This way, it can monitor the impact of the changes and take action if necessary. **There are a few things that can simplify this process:** - Automate as much of the development process as possible - A dedicated team is responsible for publishing code changes. - Use feature flags to switch new features on and off in production - Set up alerts to notify the team when you introduce new code. If you follow these tips, you can deploy code to the production environment 100 times a day. And with minimal disruption. ## Continuous deployment of small changes This insight is not new, but it is a core element of the DevSecOps movement. Another way to reduce risks is to optimise the developer workflow for rapid deployment. You can achieve this by increasing the number of employees in the development department. This not only increases the number of deployments, but also the number of deployments per developer. Even more remarkable, however, is that this has led to a decrease in the number of incidents. While the average number of rollbacks has remained the same. However, one should be careful with such metrics. On paper, they are great. But there is no 100% correlation between customer satisfaction and negative impacts on customers. Your goal should be to introduce many small improvements. They are quicker to implement, quicker to validate and, of course, quicker to roll back. In addition, small changes generally have only minor impacts on your system compared to large changes. In general, the process from development to deployment must be as smooth as possible. Any friction will lead developers to let changes balloon and release them all at once. To reduce friction within your process, do the following: - Allow developers to implement a change without having to communicate it to a manager. - Automate testing and deployment in every phase. - Allow different developers to test simultaneously and repeatedly. - Offer numerous development and test systems. Focus on a sophisticated, open, and flawless development culture in addition to a smooth development and deployment process. Only then can you deploy to production 100 times a day (or even more often). ## Our development (and company) culture At XALT, we have a specific picture in mind when we talk about our development culture. For us, a modern development culture is - one that is based on trust, - puts the customer at the centre, - uses data as the basis for decision-making, - focuses on learning, - is results- and team-oriented, and - fosters a culture of continuous improvement. This type of development culture enables our development team to work quickly, deliver high-quality code, and learn from mistakes. This approach goes hand in hand with our overall company culture. Regardless of department, team, or position. We also tend to question the status quo. I know, that sounds a bit cliché. But it is true. By allowing our team to focus on the actual problem without unnecessary friction or regulations, we are more productive and faster. Our development, testing, and deployment process looks like this, for example. It is quite simple. When one of our developers creates and tests a new code branch, only one other person needs to review the code, and it is then integrated into the production environment. But the most important core element at XALT is trust! Let me explain that in more detail. ### We trust our team We do not care how you do it or which tools you use to implement a task. We trust that you know what you are doing. If something goes wrong or something does not work, that is not a big deal. We investigate the matter, find the root cause of the error, fix it, and learn from our mistakes. I know, it is not just about development; testing and other parts are equally important. ### Monitoring and testing To become better and faster and ultimately make our users (or customers) happy, we constantly monitor and check our development processes. In the event of an incident, it is not just about getting the system running again. But also about ensuring that something like this does not happen again. That is why we have invested a lot in monitoring and auditing. This allows us to - gain real-time insights into the processes, - identify problems and potential improvements, - to take corrective action as needed and - to recover from incidents more quickly. In addition, we have introduced an automatic backup solution (daily) for our core applications and infrastructure. If something breaks, we can fall back to an earlier version, thereby further reducing the risk. ## Risk minimisation in a DevOps culture To mitigate risk in day-to-day development, we apply the following techniques: - **Trunk-based development:** This is a very simple branching model in which all developers work on the main development branch or trunk. This is the default branch in Git. All developers commit their changes to this branch and push their changes regularly. The main advantage of this branching model is that it reduces the risk of merge conflicts, as there is only one main development branch. - **Pull Requests:**With a pull request, you ask another person to review your code and integrate it into their branch. This is typically used when you want to contribute to another project or when you want someone else to review your code. - **Code Review:** In code review, the code is manually checked for errors. This is usually done by a colleague or supervisor. Conduct code reviews using tools that automate this process. - **Continuous Integration (CI):** This is the process of automatically building and testing code changes. This is typically done with a CI server such as Jenkins. CI helps to identify errors early and prevent them from entering the main codebase. - **Continuous Deployment (CD):** This is the process of automatically deploying code changes to a production environment. It is also important that we establish clear guidelines for our development team to follow. ### The guidelines at XALT: - At least one other developer reviews all code changes before we merge them into the main codebase. - To create and test code changes before we bring them into the main codebase, we have set up a Continuous Integration server. - Use of tools such as Code SonarQube to ensure code quality and provide feedback on potential improvements. - Implementation of a comprehensive automated test suite to find bugs before they reach production. ## Summary The success of a software company depends on its ability to regularly deliver new features, fix bugs, and improve code and infrastructure. This can be difficult, as there are numerous components being worked on, and releasing code changes can easily lead to new bugs. There are a few things that can make this process easier: automate the process as much as possible, assemble a dedicated team responsible for releasing code changes, use feature flags to switch new features on and off in production, and set up alerts to notify the team when new code is deployed. If you follow these tips, you should be able to go live 100 times a day while causing only minimal disruptions. ## Ready for more deployments per day? We help you build a CI/CD pipeline and engineering culture that supports frequent, safe releases. [Talk to us](https://www.xalt.de/en/contact/) --- *This version is for AI agents. Every page of this site is available as Markdown: append `index.md` to its path. Index of all pages: [llms.txt](https://www.xalt.de/llms.txt)*