I imagine that you have quite a good UI/UX team, considering your company's focus. Will some of them contribute to Jenkins? It badly needs a revamp, and not only for the pipelines/Blue Ocean :)
Yes. We already had a lot of discussions about that. I know it's not a problem that's easy to solve and it will take some time but I'm excited about tackling it
Is there a long term plan for the Codeship domain, blog, and the content that you've generated?
I ask this because I've written content for the Codeship blog before and have links to it from my personal blog. If the content is going to vanish I'd like to publish it directly rather than have it lost to the ether.
Having seen this before firsthand (even when told it wasn't going away), I'd recommend you take a few moments to make copies of anything you might want in the future.
Hi! Manny here. It certainly won't be lost. We'll let our blog contributors next steps once they are defined! We'll certainly continue publishing articles.
You are right, you never know. I think CloudBees is trying hard to do it the right way and ensure that the result is better products for our customers. That means doubling down on both, Codeship and Jenkins and figure out ways to align the products more (eg. Codeship pipeline configuration and Jenkins pipeline configuration).
Hey there, live chat is still available on some of the pages. Could you let me know where you're missing it?
That said, we try to get most support requests via https://helpdesk.codeship.com (or the widget shown in app), since complex technical problems are usually not that easy to resolve using a live chat tool.
I'm surprised we haven't seen more consolidation of companies whose primary product is related to developer experience.
I always thought either Github or Microsoft would start snatching up all these small companies to integrate them more tightly to sell as end to end packages.
Anyone in this space have any insight into why that hasn't happened yet?
GitLab has been doing an excellent work of integrating CI/CD tools with their code hosting solution; I'm guessing thats what you're talking about.
Specifically for Github, I believe they want to focus on hosting and developing (reviewing and managing) code and not on owning the CI/CD tools. They do provide many many integrations with different tools (TravisCI, Jenkins etc.). Which is a good thing: I want Github to be working on making code development better and remain agnostic of pipeline tools, which come and go as fashion dictates (OK I'm being a little harsh but my point is that I should be able to choose my CI/CD tools while having all my code live in Github).
It would benefit Github to own a CI/CD tool if said tool was used in the vast majority of projects and there was little worry about disrupting the rest. E.g. if Codeship was used by 99% of Github customers it would totally make sense for them to purchase the co and integrate more tightly.
But since the pipeline space is varied and rich, as you say, they benefit quite a bit by being a centralized tool that connects to all of them. Just pointing out that should that change in the future (in some unrelated area, say code review as a service?) we could very well see GH plop down a ton of cash and break out of that "code development tools" vertical.
I think that's a good point. There's quite some fragmentation in the cloud CI/CD space (if we look beyond Jenkins). If necessary, GitHub could still acquire down the road. The downside risk is small.
I think the majority of developers & companies doesn't want one product that does everything. It's better for the user to have clear APIs, solve specific problems very well and then make it easier to integrate with other products. It should all be building blocks that work well together. You should be able to use, e.g., GitHub because you prefer it over Bitbucket, integrate it with Codeship (or whatever other CI/CD solution you like) and then add other products like Percy or Code Climate as needed. There's a use case, and some people prefer to get everything out of one hand, but if we look at how software is getting purchased nowadays, it's more and more team-focused, fewer company-wide purchases. That's great. Pick the tools and products that solve your specific problem very well, as long as they integrate well with what the rest of your team uses.
Now that doesn't mean you couldn't build a company that does everything, or that Microsoft couldn't start acquiring and then does everything (they kind of doing it already, same with AWS). What we can see, though, is that the quality of specific products isn't that great. That's not surprising. It's easier to do a few things very well vs. 200 things.
> It's better for the user to have clear APIs, solve specific problems very well and then make it easier to integrate with other products.
At my company, some teams use the integrated GitLab CI features and other teams use a linked Jenkins instance, and both work well with Sonar. The only thing that is not linked automatically to this (or, at least, not in the best possible way) is the Atlassian stack because the integration plugins needed cost a boatload of money.
> What part of the Atlassian stack are you missing in GitLab?
Well, customers and our employees are used to JIRA and Confluence. What I am talking about is proper automated linking of Gitlab branches/MRs/commits to (multiple) JIRA tickets and Confluence pages and vice versa. Basic interfacing is working but it could be done better if we'd shell out thousands of dollars per year.
Microsoft already has an excellent easy to use hosted CI/CD platform with Visual Studio Team Services. You can either use hosted build agents or on prem build and deployment agents.
And such confusing naming yet again. Makes it sound like a cross between Visual Studio IDE (the heavyweight version) and the god awful Team Foundation Services.
It's a rebranding of Team Foundation Services, tbh. They've done a lot to improve it over the years, but as someone who is forced to work with it daily I'd still take just about anything else - better than it used to be doesn't make it a "good" product by far.
There’s still no way to describe your build as code or configuration in your source repository like travis.yml, Jenkinsfile, etc. which I consider a key feature of a relatively modern CI/CD tool.
Beyond that, the new build tooling isn’t half bad - leaps and bounds ahead of the nasty XML nightmare which is why our team has been moving back to it from out TeamCity deployment.
Most of my gripes with VSTS are around the rest of it, everything under “Work” has barely been touched since TFS 2012 - it got a coat of paint but it’s still the same enterprise-grade turd that makes me yearn for JetBrains YouTrack every day. They’ve had adequate git support for a while but the web-based repository browser is such a chore to use that I end up cloning a repository to do a quick search more often than I should need, the admin interface is still a mess to navigate, the list goes on.
There’s still no way to describe your build as code or configuration in your source repository like travis.yml, Jenkinsfile, etc. which I consider a key feature of a relatively modern CI/CD tool.
Your build and deployments are just a JSON file that you can export and import either from the web or the API.
The other parts of VSTS are obtuse. But since my chosen workflow is Kanban, it's quite easy to setup a Kanban board with WIP Limits.
What I really hate is the Wiki. It supports basic Markdown without all of the bells and whistles of Atlassian but its okay.
Being able to quickly export and import build configurations isn’t where the value of having them stored in a human-editable format comes from - your build tooling is part of your project and evolves with it, being able to arbitrarily build any commit regardless of whether your current build pipeline can support it or not is invaluable, as is being able to change the pipeline on a WIP branch while not breaking master.
The Wiki is pretty terrible too, but I’ve never found a wiki that makes me go “wow, this is AWESOME” either - dokuwiki got reasonably close though because it gets the hell out of the way and offers just enough formatting without letting me choke on markup like MediaWiki or the WYSINWYG hell of Confluence.
I believe referring to it should be in the repository along with code, versioned, and sycned with the repository - like travis.yml. I actually think he/she made that pretty clear with the use case of referring to previous commits and previous build steps. Most non clicknext developers will forget the extra step of uploading it in the web ui, and/or won't care to version the microsftvisualstudioteamfoundationservices.json seperately
It's not about "should", it's s preference. I hardly ever need to redo my builds once they are created.
Releases on the other hand, I could see a need to change more frequently. If that's your desire, there is nothing stopping you from having one release step that runs a Powershell script, Cake script, etc that is run from your repo.
