Developers, Ops, Designers, PMs, and others need an easy way to see a merge request running live to properly review the request before it is deployed to production. Examples:
Earlier suggestion for three UI steps from #3286 (closed)
Everywhere where there should be commit status checks (commits, tags, branches, releases) there is also a 'D' icon to trigger a deploy.
When you press the 'D' icon you see the /group/project/deploy/new screen that lets you choose between deploying as an existing tag (if that commit is already tagged), creating new tag, a commit, a named environment (if any exist) or naming a new environment. The tag/commit environments can be seen as a staging environment per branch similar to Teatro, Tutum or Heroku Review Apps. The named environments are things like: staging, acceptance, pre-production, production, customer-13, sids-quick-test, etc.
After you specified what environment you want to deploy on you see the environment show screen. This has the deploy status (updated 5 of 25 containers), settings (can add more workers), hostname and ports (with links), a history of deploys on this environment (including 'rollback to' buttons), a button to shut down the environment and a link to the pod in Kubernetes (if it doesn't have a web interface show how to query the api).
@sytses I can see the value in being able to manually deploy to any environment, but for me, the real value of Review Apps is that they're created automatically for every merge request. At Heroku, we did eventually add the ability to manually create a review app because some users had valid cases where automatic creation wasn't feasible or cost-effective, but we started from the position of creating them automatically. Waiting ~10 seconds for an app to spin up is acceptable, but waiting 30s up to several minutes to do a deploy on the fly ruins the experience. It also gets complicated with permissions since the person wanting to see the app may not have permissions to deploy the app.
@markpundsack I guess my proposal was a hybrid between manual deployments and review apps. The advantage of it was that you wouldn't have to specify manual deployments in .gitlab-ci.yml ahead of time. But I agree that review apps should be automatic. Let's first do that before we dive into more complications in subsequent releases.
I would leave that issue to have more general discussion about full lifecycle of review apps, and have https://gitlab.com/gitlab-org/gitlab-ce/issues/21971 describing a first iteration and basic implementation concepts.
As I understand review app feature is tightly coupled with gitlab-ci CI? There is no open API/hook to interact with gitlab-ce in order to deploy app using other CI system. I understand the fact you are focusing on gitlab-ci but in our case we already have kind of review app feature using jenkins (just a on-demand deployment per branch) but there is no integration with gitlab-ce UI unlike review app feature
@kakawait Correct, this is tightly coupled with gitlab-ci.yml, but eventually we'll have an API for management of environments and deployment history, so the Jenkins integration could write that information back to GitLab and you'd get some of the benefits (such as seeing the review app URL in merge requests). I expect the same thing to be useful for Heroku since they already have formal Review Apps. I believe there's already an API to query environments, but not sure about creating them.
@markpundsack thank you for response. I don't expect that gitlab-ce will support jenkins or whatever like heroku but the idea about open an REST api to allow integration is really what I wish, like you just suggest above (from doc there is no api to create environment). I will close discussion here because I think is more about environment feature and not directly specific to that issue and review app