Every IaaS provider (Google, Amazon, Azure) has added a code hosting service or will do so in the future. Having your code hosted here will increase lock-in which is the best way for the IaaS provider to increase margins in the future. However, code hosting is not the essence of that GitHub, BitBucket and we at GitLab offer. The essence is code collaboration: mentioning people, doing a code review, activity streams, etc. Getting this right is hard and I wonder if many IaaS providers will get this right.
The code delivery pipeline consists of issues, IDE, code hosting, CI, code review, configuration management, Continuous Delivery (CD) and a PaaS service. Code hosting is a first step and getting all the rest right is a lot of work. Services working on getting the IDE right are Koding, Nitrous.io, Cloud9, CodeAnywhere, Codio and CodeEnvy. And I suspect that GitHub Atom is running in a web-browser so they can effortlessly offer it online in the future. For configuration management you want to integrate with Chef, Puppet, Ansible, Salt and Docker.
At GitLab we offer CI and CD via GitLab CI. We hope for a multi-cloud future where organizations will deploy to different cloud providers. They will use PaaS software that spans the different IaaS providers. Cloud independent PaaS software offerings are CloudFoundry, OpenStack, OpenShift, Kubernetes, Mesos DCOS, Docker Swarm and Flynn. We want to ensure that GitLab is the best option to do code collaboration upstream from these offerings.
So one thing GitLab and others don't offer that Google can is tight integration with Deployment. Yeah we have all used the CI servers to do a form of Continous Delivery, but can google and amazon surpass those offerings by giving a tighter integration that a third part can't offer.
Right now our support for deployments is lacking. On the short term we'll add documentation how to use the Travis DPL gem to push to the IaaS providers.
Currently we're thinking about solving this problem, but in our opinion it is more than a simple deployment. You need a build pipeline.
We're thinking about adding a build pipeline configuration to .gitlab-ci.yml file. Right now we're looking into how to deal with dependencies that trigger a build and how to allow for multiple environments (staging, preprod, prod) to be deployed.
We think that solving the build pipeline properly (like GoCD and Concourse already have) in a simple to setup way will offer a lot of value. What do you think?
> And I suspect that GitHub Atom is running in a web-browser so they can effortlessly offer it online in the future.
A note about atom ... It does not run in a web browser and it would be damn hard to port it to the web since it runs on Node. It uses chromium for displaying the DOM but is not in a browser.
The code delivery pipeline consists of issues, IDE, code hosting, CI, code review, configuration management, Continuous Delivery (CD) and a PaaS service. Code hosting is a first step and getting all the rest right is a lot of work. Services working on getting the IDE right are Koding, Nitrous.io, Cloud9, CodeAnywhere, Codio and CodeEnvy. And I suspect that GitHub Atom is running in a web-browser so they can effortlessly offer it online in the future. For configuration management you want to integrate with Chef, Puppet, Ansible, Salt and Docker.
At GitLab we offer CI and CD via GitLab CI. We hope for a multi-cloud future where organizations will deploy to different cloud providers. They will use PaaS software that spans the different IaaS providers. Cloud independent PaaS software offerings are CloudFoundry, OpenStack, OpenShift, Kubernetes, Mesos DCOS, Docker Swarm and Flynn. We want to ensure that GitLab is the best option to do code collaboration upstream from these offerings.