3 ms·

If I understand correctly, this creates an environment for each PR. How does it accomplish that exactly? It would require all Kubernetes manifests for resources

If I understand correctly, this creates an environment for each PR. How does it accomplish that exactly? It would require all Kubernetes manifests for resources somewhere in the repo? What if the environment has some stateful dependencies, etc?

jstrachan 8y ago
Jenkins X creates a Preview Environment per Pull Request yeah; which can be as much or as little as you want it to be. e.g. it could be just 1 pod only or could be a suit of related apps (you may want to test multiple things together). You can define what a Preview Environment is in the source code of your application - its just a different Helm chart really. You can of course opt out of Preview Environments completely if you wish. http://jenkins-x.io/about/features/#preview-environments http://jenkins-x.io/about/features/#preview-environments Though I've personally found them to be super useful - especially if you are working on web consoles - it lets you try out changes visually as part of the Pull Request review process before you merge to master.
jstrachan 8y ago
BTW we're hoping to make it easier to 'service link' your Preview Environments to other environments. https://github.com/jenkins-x/jx/issues/573 https://github.com/jenkins-x/jx/issues/573 e.g. so you could deploy just your front end in a Preview Environment but link it to all the back end services running in the Staging or Production environment. Each team can configure their Preview environment helm chart however they wish really. Using separate namespaces in kubernetes is a great way to keep software isolated and avoids apps interfering with each other; but at the same time its really handy to be able to link services between namespaces too.