However, moving these artifacts to "higher environments" (e.g. We have the concept of a "release" as a tagged collection of build artifacts for multiple services which are deployed to a cloud environment.Įasily migrate to the cloud and innovate incredibly fast with Kalix! Build high-performance microservices and APIs, NoOps needed.
#Blue green full#
Our team’s applications are relatively modern and flexible - hosted in Docker containers and deployed automatically to the cloud, unit and component tests run on changes, and deployment can continue automatically once a full suite of automated tests have passed and code quality gates have been met. It all starts well enough with a desire to improve releases so that we can get changes into production more often. How did this happen? It’s quite an interesting background, and I wonder how common such things are. Creating these kinds of dependencies ties us to a specific platform and release method, and the extra code opens up a world of possible bugs and errors that could vary per environment and as such are extremely difficult to test for. It flags a warning to me as a code change – tying deployment to code writing code to support the environment when the environment should be invisible and interchangeable. I wasn't keen on the solution they were proposing – namely, specific changes in our application code base to support blue-green releases. The other week I was driven to withhold a " thumb of approval" on a merge request to our GitLab project.
0 kommentar(er)
