10 ms·

This is great news for developers. The trend has been to combine version control and CI for years now. For a timeline see https://about.gitlab.com/2019/08/08/bu

by sytse 7y ago

This is great news for developers. The trend has been to combine version control and CI for years now. For a timeline see https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/ https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-c... This is bad news for the CI providers that depend on GitHub, in particular CircleCI. Luckily for them (or maybe they saw this coming) they recently raised a series D https://circleci.com/blog/we-raised-a-56m-series-d-what-s-next-for-circleci-customers/ https://circleci.com/blog/we-raised-a-56m-series-d-what-s-ne... and are already looking to add support for more platforms. It is hard to depend on a marketplace when it starts competing with you, from planning (Waffle.io), to dependency scanning (Gemnasium acquired by us), to CI (Travis CI layoff where especially sad). It is interesting that a lot of the things GitHub is shipping is already part of Azure DevOps https://docs.microsoft.com/en-us/azure/architecture/example-scenario/apps/devops-dotnet-webapp https://docs.microsoft.com/en-us/azure/architecture/example-... The overlap between Azure DevOps and GitHub seems to increase instead of to be reduced. I wonder what the integration story is and what will happen to Azure DevOps.

deleted 7y ago
[deleted]
Axsuul 7y ago
I don't think it's that bad for CircleCI. CircleCI's focus is CI/CD and it's highly unlikely GitHub is going to do it as well as them. It's hardly commoditized technology. Their current customers are already heavily integrated with them and their orbs offering is further solidifying that relationship. Also, GitHub is expanding the CI/CD market with Actions so competitors in this space are likely to benefit. Furthermore: - waffle.io was acquired and shutdown by the acquiree - TravisCI was sold to a private equity firm and lost their way
- rumanator 7y ago
  > it's highly unlikely GitHub is going to do it as well as them. They don't need to. They only need to be able to run tasks in sequence when triggered by some event, and the rest just builds itself. An integrated solution that bundles issue tracking, CICD pipelines, and package/container repository always beats spreading each feature throughout multiple separate service providers.
  - Axsuul 7y ago
    > An integrated solution that bundles issue tracking, CICD pipelines, and package/container repository always beats spreading each feature throughout multiple separate service providers. I agree but with GitHub actions, it's also possible for CircleCI to build a tight integration. When it comes down to it, each CI system has its idiosyncracies so choosing a CI system isn't as simple as how tightly integrated it is (e.g. how flexible it is with Docker, or the way it builds containers, or running multi-container setups)
- lbotos 7y ago
  > I don't think it's that bad for CircleCI. CircleCI's focus is CI/CD and it's highly unlikely GitHub is going to do it as well as them. I don't think it's bad for entrenched CircleCI users, sure, but I do think it's bad for prospective CircleCI users, who, are likely using GitHub already, so why would they not use something tightly integrated? If you don't think GitHub is going to try and increase adoption of this tool then why did they build it? (Work at GitLab; Opinions are my own)
rmetzler 7y ago
I think a good strategy for Microsoft would be to reuse as much as possible CI/CD code from github in Azure devops. Azure devops probably doesn’t need to be as flexible as long as it is robust and just works. Github will probably be the place where experiments can happen.
- pas 7y ago
  Azure Pipelines is currently considered the best CI/CD solution. (For example see GitLab issues about how users would like GitLab to improve theirs.)
  - twalla 7y ago
    [citation needed]
    - Guillaume86 7y ago
      I'm in the process of replacing TeamCity with Azure Pipelines (not my choice). It's ok but I also doubt it's best in class, TeamCity is far better IMO (more flexible, more informations/actions on one screen, less clicks, better logs display, better tests results display, live tests results, etc). I wish they had an hosted offer, and yaml configuration.
    - pas 7y ago
      Can't find the discussion now on GitLab, but I recall comments claiming that Azure Pipelines is very flexible, and GitLab CI's new task DAG should be modeled after that.
  - kkapelon 7y ago
    Last time I checked Azure Pipelines still doesn't have build caching https://developercommunity.visualstudio.com/content/idea/365799/improve-hosted-build-agent-performance-with-build.html https://developercommunity.visualstudio.com/content/idea/365... F.S. I work for Codefresh a CI/CD solution
    - 7y ago
snitko 7y ago
It's a horrible trend. CI should not be tied to version control. I mean we all have to deal with it now, but I'd much rather have my CI agnostic and not have config files for it checked into the repo. I've browsed through the article you linked to, one of the subtitles was "Realizing the future of DevOps is a single application". Also a horrible idea: I think it locks developers into a certain workflow which is hard to escape. You have an issue with your setup you can't figure out - happened to me with Gitlab CI - sorry, you're out of luck. Every application is different, DevOps processes is something to be carefully crafted for each particular case with many considerations: large/small company, platform, development cycle, people preferred workflow etc. What I like to do is to have small well tested parts constitute my devops. It's a bad idea to adopt something just because everyone is doing this. To sum it up, code should be separate from testing, deployment etc. On our team, I make sure developers don't have to think about devops. They know how to deploy and test and they know the workflow and commands. But that's about it.
- clinta 7y ago
  I'm an operations guy, but I think I have a different perspective. The developers I work with don't have to think about CI/CD, but the configuration still lives in the repo, I'm just a contributer to that repo like they are. Having CI configuration separate from the code sounds like a nightmare when a code change requires CI configurations to be updated. A new version of code requires a new dependency for instance, there needs to be a way to tie the CI configuration change with a commit that introduced that dependency. That comes automatically when they're in the same repo.
  - snitko 7y ago
    I hear you. I thought about it and I think you need to reframe the problem. If a change in the application breaks your CI, it means you need to adjust the CI so it doesn't break when such changes are introduced. In my experience, these kinds of things happen very rarely.
    - dharmab 7y ago
triceratops 7y ago
Any reason CI providers couldn't start adding repo hosting?
- acjohnson55 7y ago
  Sure! This is how Heroku works. Although, if you also mean change management (issues, code review, browsing, etc), that's a much bigger lift, especially if your intention is to outdo GitHub.

by sytse 7y ago

deleted 7y ago

[deleted]

Axsuul 7y ago

I don't think it's that bad for CircleCI. CircleCI's focus is CI/CD and it's highly unlikely GitHub is going to do it as well as them. It's hardly commoditized technology. Their current customers are already heavily integrated with them and their orbs offering is further solidifying that relationship. Also, GitHub is expanding the CI/CD market with Actions so competitors in this space are likely to benefit. Furthermore: - waffle.io was acquired and shutdown by the acquiree - TravisCI was sold to a private equity firm and lost their way

rumanator 7y ago
> it's highly unlikely GitHub is going to do it as well as them. They don't need to. They only need to be able to run tasks in sequence when triggered by some event, and the rest just builds itself. An integrated solution that bundles issue tracking, CICD pipelines, and package/container repository always beats spreading each feature throughout multiple separate service providers.
- Axsuul 7y ago
  > An integrated solution that bundles issue tracking, CICD pipelines, and package/container repository always beats spreading each feature throughout multiple separate service providers. I agree but with GitHub actions, it's also possible for CircleCI to build a tight integration. When it comes down to it, each CI system has its idiosyncracies so choosing a CI system isn't as simple as how tightly integrated it is (e.g. how flexible it is with Docker, or the way it builds containers, or running multi-container setups)
lbotos 7y ago
> I don't think it's that bad for CircleCI. CircleCI's focus is CI/CD and it's highly unlikely GitHub is going to do it as well as them. I don't think it's bad for entrenched CircleCI users, sure, but I do think it's bad for prospective CircleCI users, who, are likely using GitHub already, so why would they not use something tightly integrated? If you don't think GitHub is going to try and increase adoption of this tool then why did they build it? (Work at GitLab; Opinions are my own)

rmetzler 7y ago

I think a good strategy for Microsoft would be to reuse as much as possible CI/CD code from github in Azure devops. Azure devops probably doesn’t need to be as flexible as long as it is robust and just works. Github will probably be the place where experiments can happen.

pas 7y ago
Azure Pipelines is currently considered the best CI/CD solution. (For example see GitLab issues about how users would like GitLab to improve theirs.)
- twalla 7y ago
  [citation needed]
  - Guillaume86 7y ago
    I'm in the process of replacing TeamCity with Azure Pipelines (not my choice). It's ok but I also doubt it's best in class, TeamCity is far better IMO (more flexible, more informations/actions on one screen, less clicks, better logs display, better tests results display, live tests results, etc). I wish they had an hosted offer, and yaml configuration.
  - pas 7y ago
    Can't find the discussion now on GitLab, but I recall comments claiming that Azure Pipelines is very flexible, and GitLab CI's new task DAG should be modeled after that.
- kkapelon 7y ago
  Last time I checked Azure Pipelines still doesn't have build caching https://developercommunity.visualstudio.com/content/idea/365799/improve-hosted-build-agent-performance-with-build.html https://developercommunity.visualstudio.com/content/idea/365... F.S. I work for Codefresh a CI/CD solution
  - 7y ago

snitko 7y ago

It's a horrible trend. CI should not be tied to version control. I mean we all have to deal with it now, but I'd much rather have my CI agnostic and not have config files for it checked into the repo. I've browsed through the article you linked to, one of the subtitles was "Realizing the future of DevOps is a single application". Also a horrible idea: I think it locks developers into a certain workflow which is hard to escape. You have an issue with your setup you can't figure out - happened to me with Gitlab CI - sorry, you're out of luck. Every application is different, DevOps processes is something to be carefully crafted for each particular case with many considerations: large/small company, platform, development cycle, people preferred workflow etc. What I like to do is to have small well tested parts constitute my devops. It's a bad idea to adopt something just because everyone is doing this. To sum it up, code should be separate from testing, deployment etc. On our team, I make sure developers don't have to think about devops. They know how to deploy and test and they know the workflow and commands. But that's about it.

clinta 7y ago
I'm an operations guy, but I think I have a different perspective. The developers I work with don't have to think about CI/CD, but the configuration still lives in the repo, I'm just a contributer to that repo like they are. Having CI configuration separate from the code sounds like a nightmare when a code change requires CI configurations to be updated. A new version of code requires a new dependency for instance, there needs to be a way to tie the CI configuration change with a commit that introduced that dependency. That comes automatically when they're in the same repo.
- snitko 7y ago
  I hear you. I thought about it and I think you need to reframe the problem. If a change in the application breaks your CI, it means you need to adjust the CI so it doesn't break when such changes are introduced. In my experience, these kinds of things happen very rarely.
  - dharmab 7y ago

triceratops 7y ago

Any reason CI providers couldn't start adding repo hosting?

acjohnson55 7y ago
Sure! This is how Heroku works. Although, if you also mean change management (issues, code review, browsing, etc), that's a much bigger lift, especially if your intention is to outdo GitHub.