The 3 main steps of a Software Factory, Continuous Integration, Delivery & Deployment
Developing and releasing software is quite often a complicated process. Some challenges companies are faced with, are either related to Field, development within multi-sites teams (inside a multinational company) and reduction of time to market.
To face these challenges while still being able to reliably develop, test and release software, organizations have set three strategies to manage, rationalize and automate these processes:
- Step 1 – Continuous Integration: Focus on multi-time daily integration work from individual developers into the main repository. Continuous Integration aims at detecting integration issues as early as possible and accelerates collaborative development.
- Step 2 – Continuous Delivery: Focus on reducing friction during the release process, while also automating the required steps to deploy so that the code can be released at any time in a safer and controlled way.
- Step 3 – Continuous Deployments: It takes the Continuous Delivery one step further by automatically deploying a new version each time a code change is made. The goal of Software Factory is to allow your company to answer business changes as fast as possible without any friction. Development and deployment will become a non-event that can happen much time by day.
Continuous Integration: the first step to climb
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually, each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated system (including test) to detect integration errors as quickly as possible.
Continuous Integration assets in comparison to Big Bang Waterfall are integration problems reduction and teamwork. Both aim at developing software in an efficient and fast way.
Integrating code frequently does not, by itself, offer any guarantees about the quality of the new code or functionality. However, continuous integration relies on robust test suites and on automated systems to run tests, aiming at increasing the global quality of your software.
The main goal of any continuous integration methods is to make code integration simple, repeatable, and to make this process as transparent as possible as it needs to become integrally part of the everyday development workflow. Integration should be a non-event.
Any recipe for a seamless Continuous Integration deployment?
- Version control system with a clear associated workflow: Today the standard is GIT, as it has won the battle of the version control system. If you do not use it, you should have a very specific reason. Legacy reason cannot be used indefinitely, you should plan to migrate to GIT and start working as every other developer does around the world.
- Automating build
- Testing: Make Your Build Self-Testing as much as possible to detect bug as early as possible. Test Driven Development and Behavior Driven Development are two methodologies that can help you to make your code easier to test.
- Keep the Build Fast: An important point of Continuous Integration is to provide quick feedback. In pre-integration (during pull request) continuous integration should not last more than 15 minutes. However, in post-integration, code robustness testing may take several days.
Continuous Delivery: a step further of continuous integration
Continuous delivery is an extension of continuous integration. It focuses on automating the software delivery process, allowing teams to reliably deploy their code to production at any time. When you are sure that your code is in a deployable state, releasing new version becomes a non-event.
From a technological point of view, continuous delivery deeply relies on testing automation and deployment processes.
At each delivery stage, the either fails the tests, which alerts the team or passes the tests, which results in automatic promotion to the next stage.
As the build moves through the tests system pipeline, later stages aim at deploying the build to environments that mirror the production environment as closely as possible. This way the build, the deployment process, and the environment can be tested adequately. The pipeline ends up with a build that can be deployed to production at any time in a single step.
Continuous Deployment: the final goal of Sofware Factory
Continuous deployment is an extension of continuous delivery that automatically deploys each build that passes the full test cycle. Fast-rollback, blue-green deployment, A/B testing, or canary deployment are techniques allowing you to avoid version switch big-bang and to automatically deploy a new software version for a user subset before a full switch.
Automatically deploying features and fixes as often as possible to customers, encourages smaller code modifications with limited impact and help to avoid confusion disorder about what is currently deployed in production.
This fully automated deployment cycle can be a source of anxiety for organizations, as they can worry about relinquishing control of their automation system and what is really released. The trade-off offered by automated deployments is sometimes judged as too dangerous for the payoff they provide.
However, Continuous deployment also allows organizations to benefit from consistent early feedback. Features can immediately be available to users. Defects or unhelpful implementations can be detected early enough and thus allow the team to save development time. Getting fast feedback about an unhelpful implementation, allow the team to focus on what matters rather than wasting energy into an area that has minimal importance.
Continuous Deployment is the ultimate goal of automatization and process rationalization. It is already the state of art in the Web and Mobile area and it will become the state of art in a few years in the IoT/embedded/industrial environment.
Embedded Container technology will certainly play a big role for this, but this is another story that will be discussed in upcoming articles.
This article represents the end of the Software Factory series. In case you miss my other articles, follow the link below:
- Software Factory #1 : Why it matters?
- Software Factory #2 : What makes infrastructure crucial
- Software Factory #3 : TDD and BDD are in a boat…