Atlassian prepares to abandon on-prem server products
theregister.com
theregister.com
At this point the decision has been made in our org to firewall their products off the internet and internal networks, and migrate to something else by 2024.
[1] https://hn.algolia.com/?q=atlassian
[2] https://confluence.atlassian.com/security/cve-2023-22515-pri...
What options are you evaluating?
Project Managers are missing some features, but the devs (including me) like it a lot more due to integrating so well with PRs/commits.
I feel that it is breaking encapsulation in a sense to be dealing with issues at the repo level. The repo and the code are implementation details of the business requirements. The tickets describing requirements belong at the next level up of abstraction?
One way to approach this would be using Epics [0], which can live at the group-level. Child epics and/or issues can then be used for more finely tuned requirements.
I do use gitlab-ce at home for my personal projects and think it's awesome.
I would recommend it to work in terms of its features for code management and build pipelines.
But I just cannot see any of our product management team wanting to use this for Roadmap/Epic/Task tracking at all. Its far too technical and too close to the code, both of which are things they have neither the time, interest or skill to interact with. Management are comfortable with Jira (and some of the extended Atlassian suite), as it hides the technical stuff away and allows them to focus on the management data.
I don't know what the perfect solution looks like though, and I also haven't spend the time to exhaustively try all the competing products either.
>[Roadmap/Epic/Task tracking] Its far too technical and too close to the code
I'm a Product Manager in the Plan stage at GitLab and I'd love to learn more about this impression. Would you be willing to share more either in thread or on a call?
Specially, I'm trying to understand what about the GitLab Plan tools (epics, roadmaps, etc) feel dev-centric?
I was really impressed.
With devs and a premium tier, this isn't bad... but the "ok, we need to double the user count and move from premium to ultimate, even though most people are only looking for multi-level epics and the reporter role." That represents a significant cost increase.
Taking all the devs from $29 to $99 and doubling the accounts is a lot more than $15 per account (devs, ba/pm/mgr, business).
I double as a product manager and CTO, meaning I do both code and planning. We're using Github issues and Asana. Both have their strengths and weaknesses. I'd take both over Jira any day. And since I'm in charge, my company is blissfully free of anything Atlassian.
I kind of like Asana for planning. It's got a few sane features one of which is separating issues from projects. This allows me to quickly plan out projects and then add tickets to the relevant team boards. And another one is making it very easy to create issues in a spreadsheet like view that minimizes the click bureaucracy other tools have. Great when you basically are thinking at the bullet point level and just want to hit enter instead of having to fiddle with obnoxious modal forms.
Of course for developers Asana isn't great because it has no markdown support and no usable github integration (a few commercial things exist but they are basically glorified sync tools). Github issues have a few nice features as well. I like working with check lists and then converting the individual items to tasks. That comes close to how I like to use Asana.
Where Github falls off a cliff is what passes for project management. I don't know what their PMs were smoking but it's just completely wrong and useless. It kind of lives orthogonal to issues (!!!!!) and nothing syncs automatically except with really awkward github actions crap. So, it only serves to add a lot of bureaucracy and busy work without actually addressing the core problem. A combination of over engineered and inadequate.
The core issue with Github is that issues are tied to a single code repository. From a planning point of view that is just horrible because I manage a product consisting of multiple code repositories and I need one plan that may involve zero or more code repositories and not several and I don't want to lock in my issues to a single repository before I have even figured out what the plan is. I guess that's what they tried to fix with their project management thingy. Except they messed that up badly.
I'd love a tool that is a bit like Asana but more integrated with pull requests, CI/CD, the notion of work being distributed across multiple code repositories, teams, etc. I don't mean yet another sync thingy that copies tickets from system X to system Y. I would like a one stop shop that can be used throughout the life cycle of a software product from before any code is written until users / customers start reporting issues and everything in between. Doesn't exist.
TFS' UX is hardly any worse than Jira's.
BTW, if your complaint is based on your personal experience dealing with hideously complex Issue/Bug form-fields, "areas", and the like, then that's not so-much an issue with TFS/AzureDevOps, but with your PMs, who are the ones responsible for applying customizations to the built-in workflow forms. The stock workflow forms/fields are a (relative) breeze to use compared to Jira, IMO (but GitHub Issues+Projects are better, I agree).
Microsoft is still playing "will they/won't they" with killing Azure DevOps for whatever reasons make sense mostly only to themselves, but it is hard not to wonder if the writing is on the wall to migrate to something like GitHub Enterprise sooner rather than later.
(Arguably yes, running GHE is different than Azure DevOps Server, as it is still mostly not Microsoft-stack. But I'm told they package it in a friendly enough way that even companies deep in Microsoft-stack-only don't have too many problems.)
It seems like one of those rumors that doesn’t die, and then just becomes self-fulfilling if they ever do announce it.
You can read that roadmap for yourself. It is kept in a GitHub repository. Last time I checked this year the last commit was sometime in 2020. The last group of features that loudly launched for Azure DevOps were branded "GitHub Advanced Security for Azure DevOps". (This is where I get the 2-3 years behind GitHub metric.) Microsoft's actions seem to be speaking a lot louder than their "on the record" words.
I've heard from multiple "off the record" sources who are entirely hearsay and I cannot name names that "Yes, of course Azure DevOps is dead."
The best, I can say, as mostly an outsider is that Azure DevOps is at least "undead" and definitely in some sort of zombie state. I've got an unsubstantiated feeling, again as mostly an outsider, that Microsoft is somehow superstitious about Azure DevOps' home office (Microsoft office in North Carolina was founded out of Microsoft's source control dreams) and is afraid to kill it.
…but I’ve noticed that GitHub’s recently (since 2020?) has really being fleshing-out their Projects/Issues - it’s not quite as flexible as TFS/AzDO’s Work-Items but on-track to reach parity in a few more years, I reckon.
So that’s my pet-theory: eventually GitHub (and GitHub Enterprise) will reach “good-enough” parity with AzDO for Issues/Work-Items/Project management - and as soon as that happens I fully expect AzDO to die an unceremonious death (because MS doesn’t want to spook the many Enterprise(TM) customers who still bankroll it). We may-or-may-not see some improvement in AzDO-to-GitHub migration tooling, as that that comes down to what side of the bed the Director of the ALM team woke up on that morning.
I'm mostly aware of it from GitHub Universe and Microsoft BUILD demonstration videos. Both of which give me a lot of signals that Microsoft internally has moved a lot faster to GitHub than it did from predecessors to TFS/TFS+git. Some of the teams talking about it are huge ones (both in terms of size but also in terms of weight internal/external to the company).
From their own hype videos in the virtual sides of the two conferences, I certainly get the impression they reached "good enough" feature "parity" with AzDO Work Items internally a year or two ago, at least. That doesn't seem like the reason they keep saying AzDO is still alive.
I do realize that AzDO has some big enough Enterprise customers though that not spooking them can be a big reason for the weird messaging despite their overt actions and all the subtle hints that AzDO is dead. But also, my understanding is that many of those customers don't entirely care if a migration needs to happen so long as they are given a migration with a far enough out deadline. [1] I know some companies seem to be acting more spooked that there isn't a deadline yet for AzDO's shutdown. (It was a factor in my last employer migrating to Atlassian's terrible products for everything but repository hosting after years in AzDO [after years in Bitbucket and Atlassian's terrible products and hating them; vicious cycle].)
I obviously don't know what Microsoft is truly waiting for at this point to kill AzDO, which gets back to that feeling that it is something fundamentally weirder such as a superstition.
[1] Case in point: no one seems to be shouting too much about the crazy Azure AD to Entra shenanigans because it has dates and timelines! The timelines don't even make sense: among other things, Azure AD B2B and Azure AD B2C both get marketed as "deprecated" months before their Entra counterparts are expected to leave "Beta" or "Preview" statuses and even more months before automated migration tools are expected to be available. But it is all a planned migration and that makes all the difference.
Space I haven't used. It seems like an attempt to reinvent both products in a GitLab style product which is a pity because the JetBrains tools are very mature and I don't think they needed a new product.
But that was a decade ago, and it could've been a misconfiguration on that team's part. It was also back when JIRA was more of a structured database with real issue types and not stories atop stories for all eternity.
Only one major complaint: For main license, you can buy and own license for selfhosted version. However for helpdesk addon it's subscription only, which sucks a lot. For Spaces they have only subscription-based pricing, even when self-hosted. I hope they don't go Atlassian way.
It lacks most collaboration options for non-developer users, but we found that they are rarely, if at all, used anyway. Non-developer users can still use an edit button that points to GitLab's web editor and update the docs that way.
I can't suggest a replacement for Jira at this point. I don't think there is one tool to recommend that fits every company's workflow. The other comments seem to have some nice tools to try.
> It lacks most collaboration options for non-developer users, but we found that they are rarely, if at all, used anyway. Non-developer users can still use an edit button that points to GitLab's web editor and update the docs that way.
Maybe the wiki in GitLab provides a possible path forward. https://docs.gitlab.com/ee/user/project/wiki/
The wiki uses the same Rich Text editor as known from issue/MR comments, aiding visual editing with context actions - for example, Markdown tables, rows, columns, or uploading and resizing images.
> Material for MkDocs.
I personally love this project. I'm using it for o11y.love and opsindev.news published via GitLab pages. Editing happens mainly in the browser, using the Web IDE.
Sources in case you are interested:
https://gitlab.com/everyonecancontribute/observability/o11y....
https://gitlab.com/dnsmichi/opsindev.news
PS: Tip for faster editing files using the Web IDE in the browser: Press `.` on a repository view which opens the Web IDE immediately.
But Linear is goated
Looking at our Confluence usage over the years, I noticed that we use it primarily as a knowledgebase/documentation tool and less for collaboration. With our on-prem license expiring, we are migrating to a dedicated knowledgebase for our FAQ and frequently changing content and switching to a Markdown tool + Git for our more formal documentation.
MkDocs includes a utility to publish to Github pages but I keep my notes on a self hosted Gitea server and serve using "python -m http".
Having hundreds of out of date, and insecure word documents is a dismal affair when you get a call in the middle of the night.
For issue resolution, documents steps are moving right in to the ticketing system for linkage to incidents. That’s fine.
For general documentation though. It doesn’t belong in the ticketing system and what a pain in my ass.
I edit using VS Code and it provides help with linking from one document to another, including navigating to the file and even linking second level ('##') headings. MkDocs can report broken links when it builds the site.
Collaboration could be through sharing a Git repo. Perhaps other other ways I can't think of at this moment. Any way you could collaborate editing text files should work.
Configuration in https://gitlab.com/dnsmichi/opsindev.news/-/blob/main/mkdocs...
Material for MkDocs also has an insiders build, accessible through sponsorship. https://squidfunk.github.io/mkdocs-material/insiders/ These features add more value to MkDocs -- I initially joined to get GDPR-compliant cookie banners and stayed to support a great project.
This is one, although you'll need to use Netlify instead of GitHub Pages proper.
Have the GH Pages (sub)domain proxied with CF, protect the URL with Zero Trust, for SSO itself there are several IdP available [0]. First 50 users are not billed.
[0]https://developers.cloudflare.com/cloudflare-one/identity/id...
I haven’t experimented, but my first attack would be to query the GH Pages service directly and specify the host header. Bypass Cloudflare entirely.
GitHub Pages supports SSO with the enterprise cloud plan, of course.
It's a fantastic tool but strictly singleplayer.
Note that multi-user auth is NOT supported out of the box however.
"Markdown is commonly used to author text-heavy content like blog posts and documentation. Astro includes built-in support for standard Markdown files that can also include frontmatter YAML to define custom metadata such as a title, description, and tags."
I respectfully disagree with that assertion! I remember 2012 (okay, 11 years ago). I had just joined a new team at work, and the documentation for the team was a lot of vendor PDFs and some .txt files from the lead stored on a network drive.
The company was just implementing Confluence, but it was slow on client and server side with no HA. That is the fault of the server team, not Atlassian, but still the software was ick.
I spun up a shadow-IT Dokuwiki server that was much easier to use for a small team with text-based documentation needs. It had a naive "calendar" plugin that allowed the quick creation of pages based on date, which we used for oncall hand-off. Backup was zipping the data folder on the server.
It was probably 3 more years until our hand was forced to use the "enterprise standard" for business continuity purposes.
The products are too complicated to be packaged nearly with a bow for sysadmins. You inevitably start having to become at Atlassian SME just to keep that shit running.
I’m all for your company going with an alternative product, but for a company who would rather stick with Atlassian products, you’d be insane to prefer the on-premise version.
Either insane or you’re a giant company with heavy compliance requirements and you don’t mind hiring a dedicated person/team to operate the data center product and babysit other on-premise vendors’ services.
In my experience, I was running an on-premise Jira installation for a <100-person company, which was an insane waste of my time compared to the other tasks I could have been doing to help build our core product.
There's also the usual stuff of finding & setting up plugins, and then looking for a maintenance window that people can agree on, while side-stepping those settings you forgot needed a restart to apply (thus bringing your live maintenance to a halt because you can't bring it offline now).
I'm curious what were actually tasks that wasted your time?
I observe load times that remind me of the 90s sometimes using their cloud apps.
Incredible they are killing on-prem, but maybe it makes it harder to compare to the slow as molasses cloud offering that way?
Yet I still cannot import anything like in the old editor (e.g. markdown), adding images in lists was added two years after forcing switching to the new editor and you still cannot continue numbered lists in another item line and have to start over.
Extensions exist to do this but these things should be standard in any editor.
I don't remember the last time I had a problem with an editor except for using any Atlassian product. Not sure what the fuck they do, but they really seem to have trouble with this aspect of their products. Which is ironic because their products are essentially CRUD products with a heavy emphasis on data entry.
Like, if anything out their products needs to work well, it's the editors.
I hate jira and don't like confluence but I've had more problems in sharepoint online editor with losing serious hours of work to synchronization bugs than confluence.
"To be clear, we have no plans to end of life or end of support for our Data Center offering."
https://community.atlassian.com/t5/Data-Center-articles/The-...
On-prem will keep existing IFF you have the capacity to pay for 500+ licenses. If you're a small to medium organization that still doesn't trust Atlassian to run your business-critical services (and there are a number of reasons why one might not want to: [0] [1] [2] [3] [4] [5] ) you're SOL.
[0] https://newsletter.pragmaticengineer.com/p/scoop-atlassian
[1] https://www.zdnet.com/article/us-cybercom-says-mass-exploita...
[2] https://cyberscoop.com/atlassian-hack-employee-data-seigedse...
[3] https://www.theregister.com/2022/07/21/atlassian_critical_se...
I would not connect any of these services directly to the Internet.
We went from Server -> Cloud -> GTFO. Server also had tiered pricing starting at $10 for 3 users. It went up from there in much saner increments but I don’t recall them.
We exited the ecosystem at the last cloud price hike. Their product pricing people are delusional.
All the talk about the office being a magnet, not a mandate... needs to apply to products as well. Magnets, not mandates.
Atlassian hasn't added much in the way of new features to the cloud instances, and the cloud options often take a lot longer to return queries.
And frankly, the "migrations" were never great... upgrading form some customized version of Atlassian (or just highly configured) to the cloud generally moved / changed things. Meh, sort of inevitable, but also really tedious. And don't get me started on how miserable "half-migrations" were where some teams moved and some didn't, or Jira moved but Confluence didn't. Those months in limbo with multiple logins and issues getting created in the wrong places were torture. Atlassian didn't really help customers with all this -- I was told they wouldn't even help us clone the Jira server so we could run migration tests... we had to do it live. (Something about Atlassian not offering another license without us paying for the test server as if it were a real server.)
Moving off Atlassian seems like a good call!
I pushed my org (at the time) to move to GitHub... we ran a test program, and it was successful, but I left the company before it was completed. I was so much happier with GitHub.
Never quite realized these were the same company. Mostly because they were forced on us, we basically did the bare minimum on those platforms, and they never took off.
They're just removing perpetual licenses for small numbers of seats (low volume). It makes sense that they want to push small customers to their cloud product, supporting on-prem software is truly laborious and best saved for your largest possible customers. That being said Atlassian is huge so they're either leaving money on the table or they're following the market. My guess is the latter.
In my recent adventures over the last few years, companies much larger than your average startup are increasingly amenable to cloud hosted services. I suspect this is in part due to how SOC2 has become so prevalent and relatively easy to obtain.
It's worse than that: it's also a reduced feature set. For example, Bamboo Server lets you use local agents but Bamboo Data Center does not.
[1] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2658
If some information is not in GitLab Git and CI, it should be in GitLab Issues or (ugly) GitLab Wiki.
Those 4 words avoid a lot of problems. Including avoiding a proliferation of silo'd and leaked and lost information in numerous different SaaSes, apps/programs, and storage services that people will tend to do by default.
> If some information is not in GitLab Git and CI, it should be in GitLab Issues or (ugly) GitLab Wiki.
Tip if you have not used it yet: The rich text editor can help with visual editing issues and the wiki: https://docs.gitlab.com/ee/user/rich_text_editor.html
For Kubernetes, we found that GitLab has a tool that automatically does that:
https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-pod-cleanu...
(which I totally understand, they are not profitable yet and have to do a lot of work. It's just that it sucks having to be cautious about who gets access to your instance since you can't have multiple tiers of users, once you use ultimate features everyone has to pay for an ultimate seat)
The stupid thing is I don’t need 90% of their ultimate features, but I do want the remaining 10%.
To me, a flat instance tier pricing + per seat cost would make so much more sense.
I get why in some sense, because once you use ultimate you switch to using a EE install instead of the CE. But I think even having the choice between ultimate and normal paid tiers would be great, even if it means no free users on the instance.
(However, to be fair the free plan includes some stuff that is only on the team plan for github, like 5gb for gitlab free vs 2gb for github teams)
> Still not a big fan of how stiff Yaml pipelines feel in Gitlab CI
Maybe the pipeline editor in "Build > Pipeline editor" can help with live linting, or more advanced features such as parent-child pipelines or merge trains.
If you need tips for optimizing the CI/CD pipeline, suggest following these tips in the docs https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.... or a few more tips in my recent talk "Efficient DevSecOps pipelines in cloud-native world", slides from Chemnitz Linux Days 2023 in https://docs.google.com/presentation/d/1_kyGo_cWi5dKyxi3BfYj...
> and that tickets for what seems like a simple feature [1] hang around for years, but it is nice.
Thanks for sharing. (FYI for everyone) The linked issue suggests a Docker cache cleanup script, which might be helpful. https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27332#n... -> https://docs.gitlab.com/runner/executors/docker.html#clear-t...
I doubt that day will ever come without a significant number of potential customers stubbornly opting to go it alone with DIY on-prem alternatives (or at least somewhat SaaS-less - e.g. turnkey-on-IaaS or similar) in the interim. Though I guess that "stubborness" might become more likely as more & more stagnation & inflexibility of cloud SaaS reveals itself to customers over the coming years.
My company's recently been pushed off JIRA on-prem to their cloud offering & the migration has already been an absolute travesty. Any gaps there might have been in the near-universal hatred of JIRA have been thoroughly wiped out by now.
edit: and in fact the DC edition is still an option.
But yeah, I think this is more dipping a toe into the water. They seem to be focusing on entirely new products with a reasonable small scope. It's interesting to see it happen, though, and they're moderately influential.
I meant 180, of course :)
If ”cloud” was available in the 90s, I doubt that self hosting would have been as popular. Not saying its a wrong choice, just a matter of convenience.
Convenience doesn’t matter. The manager will say that SaaS costs half as much and then we get the direction to move.
When the pendulum swings to “On-Premise will cost half as much”, we will get the direction to move back.
The core diff between on-prem and cloud isn't where the data is hosted. It's that in one case someone else handles UNIX BS and in the other case you do. Get a MacOS-equivalent level of usability for servers in a form that isn't rent it by the hour, and you could see such a migration, but what's the incentive for anyone to build or support that when people are willing to pay so much for cloud services?
Is it the need to CLI? Or just the number of knobs that you can frob? Too many choices?
Interested in how such a server system might look.
To compare, try comparing the docs and GUI help you get deploying a simple serverless app to Lambda+RDS vs configuring a Linux box with systemd, apache/nginx, SSL termination, postgres, borgbackup or whatever other stack you want to use. The difference is night and day. The systemd docs alone are classic Linux BS culture. UNIX sysadmin is complicated in very fundamental and deep ways for people who don't have a gray beard. I know how to do it but I don't enjoy it, and I had to recently teach a friend of mine how to do basic tasks. He's a pro software dev with years of experience incl at Google but sysadmin was never something he needed to do. Luckily now ChatGPT can help a lot with the missing usability.
I think the documentation aspect is often overlooked. Even RedHat's subscriber-only documentation is ... quite dense, and yet, not very deep.
We'll likely be running on prem as long as is reasonable without support, and then moving to an alternative - maybe gitlab. Atlassian lost our business with this move.
1. Changing default sorting order to 'most recent first'; I thought I was going insane at first when it happened
2. Making the comment box a floating page element so it always takes up about 25% screen real estate
I've been able to script these back to their old behavior but wouldn't it be nice if they added settings to toggle the behavior...
My company has been on Atlassian products for the past like 20 years so it'll be interesting to see whether we migrate to their cloud garbage or migrate off them altogether.
It takes a short time to adjust to UI changes, but settings live on forever.
I personally they haveheld back nearly every organization I've worked for in some way or another over the last 15 years. These Atlassian products are the destroyers of enjoyment, satisfaction, project management and productivity.
Issues I've encountered with Confluence and JIRA:
* Painfully slow UI.
* The confusing UX for JIRA.
* The 100x ways to accomplish the same things in JIRA.
* The fact project managers always end up going back to a spreadsheets because JIRA doesn't cut it, even though they insist they need to continue using it.
* The way people bastardize every installation of JIRA it never seems to solve the problem it was designed to solve adequately, or because that was encouraged via "plugins".
* JIRA can't be upgraded because someone installed a plugin that cannot be upgraded too, but the whole org is dependent on some functionality from said plugin.
* The pathetic search in both product.
* The shitty editor in confluence I really cannot believe anyone is still interested in using it.
* Confluence not having support for Git or some similar version control system or pull-request like process support, making everyone to afraid to make changes to documentation.
* Confluece, errors, just blows up sometimes when I go to save a document.
I get that the plugins issues aren't entirely Atlassians fault in some ways ,but in others they are. I believe their plugin implementation allowed people to way too tightly integrate with the core product, not working like "integrations" but actually having the ability to break basic work flows. It was a huge mistake.
I personally use GH issues and projects and the simplicity of it is really fantastic, when I'm forced to go back to JIRA at work, I just feel that I cannot believe I get paid to waste time wrangling these products into doing something useful.
I had a lot of hopes for Github Issues [0] but since they announced the product on last year's Universe event, there were not many news. Maybe this November they will come back with an update.
At this point, I feel Jira is like WordPress. It maybe slow and overbloated, but you can have absolutely any plugin and/or integration you can think of.
It is possible to do, I ack that we're below your 1k engineers threshold (though the OSS side is way above), but the problem isn't Github it's whether you (as an org) dictate a single SDLC that you enforce via a tool and as we aren't doing that and we're not yet encountering difficulties (beyond culture shock when people onboard and can't find what they're used to elsewhere, being Jira). By working with autonomy, and in fact embracing OSS and the community (meaning we can't hide info in internal Jira instances), it's easy to avoid Jira.
That's the rub though, many places do not want to give engineers autonomy like this.
For smaller companies, there's so many choices out there, I can understand why it's hard to decide on one.
Thanks, haven't checked those two.
> I'm surprised ServiceNow isn't trying to break into this space.
Last time I ran SNOW a few years ago, it was slowly but steadily heading into the SAP trajectory - highly-customazible per customer needs, expensive to pay and even more expensive to migrate onto. And it doesn't seem to prioritize any developer-oriented features to appeal to that crowd.
I.e., they have GitHub integration but it's not something I could convince a developer to use on a daily basis unlike Jira's one: https://docs.servicenow.com/bundle/vancouver-it-asset-manage...
Specific to this thread, though, they have much broader Github integrations available as well, including using git to manage apps authored in Studio, although there are some pain points.
More broadly, I wonder if anyone _really_ wants to be in this space if they’re not developing products specifically for developers as a core line of business. Dynamics and ServiceNow and other platforms and ERPs are great for reporting and tracking, but they often work in completely different ways than developer tooling does because they’re developed for fundamentally different roles.
There's a number of companies offering "Jira replacements" at it's either just service desk features or a ticketing system, almost as if the authors never really used a full-blown Jira (/Atlassian) setup.
People complain a lot about the UI and speed of Atlassians products, but on-prem isn't really slow, even with a ton of plugins, but you do need trained staff to manage it. The UI is because of Jira doesn't really impose much in the way of restrictions on how to use it. You can basically mix and match anyway you like, service desk tickets mixed in with SCRUM workflows... doesn't mean you should, but you can.
And that might just be the sensible thing to do. I can imagine that from a certain size, the effort of building it yourself can payoff. Especially if you take into account all the lost productivity caused by Atlassian products.
FWIW my place swallowed the DC charge for now, on the basis that we'd explore our options and possibly shift away.
Not if you're at <<500 users, which is the minimum tier for DC.
And also locking out others like local Bamboo agents.
What are minimum viable features for me? Granular (per branch) security access. Integration with AD federation and other auth providers(congnito, aws iam) and ability to give AD groups rights.
Web hooks sending and receiving. For example launch a merge request webhook(to lambda via aws api gateway, or to Jenkins). Receive a webhook as merge request approval when some Jenkins job finishes.
There is exactly zero need for your repository system also run cicd jobs. It ends up doing both tasks badly.
You'd like an example of said badness? Ok, how about this: in gitlab enterprise if you create cicd jobs/pipelines there is no way to giving someone an ability to run that pipeline without giving that person ability to push to the repository and submit merge requests. Yes, you can then set it so approval is needed before merge, protecting said pipeline, but why? There has been a ticket on gitlabs own issues page about it for years and it is still not resolved.
But wait, there is more... Gitlab enterprise has no mode of working that let's you have more than one active server at a time so goodbye horizontal scaling.
You want to scale your cicd worker nodes? They want you to use docker mashine(a deprecated product) instead of writing a Plugin like ec2-fleet for Jenkins.
It is obvious gitlab tries to funnel it's enterprise customers into saas.
As someone who managed hundreds of Jenkins instances from 2016 to 2018, Jenkins is now complete crap, stop using it. It was an ok product when the open source world offered no alternative but it's completely outdated compared to today's solutions. Deploying it sucks, its config as code format(s) are awful, the plugins are shit, upgrades can (and do) break everything, and I won't even saying anything about the design (not just the UI but also the UX and concepts).
Jenkins is not fine for anything in 2023.
None of the large companies I worked at used anything other than Jenkins for cicd (well in one place we did use azure devops server - back then called teams If I remember correctly, but that was just for one app development team).
Where they didn't use Jenkins they didn't have a dedicated cicd runner and they used github/gitlab instead. Both of these (although github less) suck for cicd IMO.
> We(as in everyone) are in a serious need of a new git server product. Just do git serving, and do it well. Preferably in a way multiple nodes can be run active-active for scaling and reliability. No need for cicd (Jenkins is fine for that, thank you very much).
You can integrate Jenkins into GitLab. https://docs.gitlab.com/ee/integration/jenkins.html Suggest considering a migration to GitLab CI/CD in your migration planning, following the updated documentation: https://docs.gitlab.com/ee/ci/migration/jenkins.html and more automated imports in https://about.gitlab.com/blog/2023/09/26/atlassian-server-en...
> Web hooks sending and receiving. For example launch a merge request webhook(to lambda via aws api gateway, or to Jenkins). Receive a webhook as merge request approval when some Jenkins job finishes.
(FYI) https://docs.gitlab.com/ee/user/project/integrations/webhook... and https://docs.gitlab.com/ee/user/project/integrations/webhook...
You can trigger a pipeline from external webhooks using a trigger token, and execute an action against the GitLab REST API. The example for triggering pipelines in https://docs.gitlab.com/ee/ci/triggers/#trigger-a-pipeline can be expanded into more actions, i.e. using the API to create MR approvals or comments.
For Python, I'd recommend looking into python-gitlab and this tutorial blog post: https://about.gitlab.com/blog/2023/02/01/efficient-devsecops...
> if you create cicd jobs/pipelines there is no way to giving someone an ability to run that pipeline without giving that person ability to push to the repository and submit merge requests. Yes, you can then set it so approval is needed before merge, protecting said pipeline, but why? There has been a ticket on gitlabs own issues page about it for years and it is still not resolved.
Please share the URL :)
When creating a new GitLab project, the default branch is protected by default, and only maintainer roles can push to the default branch. https://docs.gitlab.com/ee/user/project/protected_branches.h...
A developer role can create non-protected Git branches, merge requests, and as such trigger a pipeline from a merge request. You've mentioned approval rules as a safeguard already - CODEOWNERS can be an additional way to ensure that review workflows are followed. https://docs.gitlab.com/ee/user/project/codeowners/
You can also use branch protection rules to allow `No one` for push actions, i.e. any branch that matches the pattern, except for `main` or git tag patterns. https://docs.gitlab.com/ee/user/project/protected_branches.h...
> Gitlab enterprise has no mode of working that let's you have more than one active server at a time so goodbye horizontal scaling.
Suggest reviewing the reference architectures documentation in https://docs.gitlab.com/ee/administration/reference_architec... to decide whether horizontal scaling is needed for your environment.
For distributed environments, suggest looking into Geo: https://docs.gitlab.com/ee/administration/geo/index.html
> You want to scale your cicd worker nodes? They want you to use docker mashine(a deprecated product) instead of writing a Plugin like ec2-fleet for Jenkins.
The current GitLab CI/CD runner architecture involves docker-machine, based on a fork maintained by GitLab. This fork receives security and bug fixes to ensure users and customers can rely on auto-scaling in production. https://gitlab.com/gitlab-org/ci-cd/docker-machine#%EF%B8%8F... Please review the support statement in https://gitlab.com/groups/gitlab-org/-/epics/2502 to learn more for how long the fork remains supported.
The new auto-scaling architecture provides a task scheduler, and so-called fleeting plugins. You can review the architecture blueprint in https://docs.gitlab.com/ee/architecture/blueprints/runner_sc... and follow the documentation in https://docs.gitlab.com/runner/runner_autoscale/
If you prefer a timeline, please follow the Docker Machine Replacement Project Plan in https://gitlab.com/groups/gitlab-org/-/epics/6995 For example, the AWS EC2 Fleeting plugin is available in Beta since GitLab 16.5 and scheduled for 16.7 GA, see the epic https://gitlab.com/groups/gitlab-org/-/epics/8856
When using Kubernetes, you can take advantage of the Kubernetes executor to auto-scale pods. https://docs.gitlab.com/runner/executors/kubernetes.html
To optimize the CI/CD infrastructure next to auto-scaling, these tips might be handy, too: https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency....
> into saas.
Next to GitLab self-managed and SaaS, you can also use GitLab Dedicated, where you get access your own isolated cloud instance. https://about.gitlab.com/blog/2023/08/03/building-gitlab-wit...
I wonder where they actually put in the billions of dollars they've raked in from their customers - from the looks of it, definitely not in the product, and also not in support given that it's very obvious that their first line of support is some Indian guys in a callcenter with the complete inability to do more than follow a badly written script.
This is a huge fuck you to mid sized businesses that can't go into the cloud because of multiple reason such as certain plugins that cont be used etc. etc.
What is a business supposed to do? Pay the $45k or spend 10 times that to find a mediocre replacement that doesn't exit and go through the grueling process of getting out of a vendor lock in? Worst part is of the replacement isn't open source you end if up the same shit again.
Or go completely open source
but their decision to abandon on-prem has resulted in the company migrating away from all atlassian products
the best thing atlassian have ever done!
They are only dropping the small-business targeted Server tier, they are keeping the enterprise targeted Datacenter tier. It's pretty much a drop-in replacement, with extra capabilities. And annual payment instead of initial+upgrades payment.
Once they get the government tick off approval they’ll kill off hosted versions completely.
Last I heard they hired some guy to help with their FedRAMP certification, then got found out for blackmailing his previous employer (I guess HR didn’t Google him during hiring): https://www.bleepingcomputer.com/news/security/it-worker-jai...
RANT: This force to cloud is total BS though and the S*T that Postman just pulled reinforces my general disdain for 'forced' cloud. Hopefully comps. will realize this and fill this spot in the market. RANTOFF
I suspect that many server vendors are trying to go this way.
It actually makes a lot of business sense. It can have more to do with controlling the brand, and consolidating support, than just screwing over customers.
But I got fairly sick of Atlassian's stuff, many years ago, so it isn't my monkey, and isn't my circus.
Not even considering moving to that dumpster fire.
Atlassian support has been decent to good and I’ve rarely had to even contact them, you could almost always find what you needed on the support site or via a search.
They charge a lot for it, but the option is there.
Why? They probable have a bunch of large customers who will never accept going to a public cloud.