We’re preparing for Bamboo 8.0, which will be our first Data Center release. To make sure our app vendors and customers with written in-house apps are prepared, we’re launching Bamboo 8.0 Early Access Program (EAP). This is the final one, including Java 11 support and Project level build resources.
This release will bring a number of breaking changes related to Java 11, Lucene, CVS, and Mercurial support. More information can be found in the release notes.
What are the new features available in this EAP?
Improved build resilience - eliminates the loss of long-running builds in the event of an outage
Cold standby HA - enforces redundancy and enables a quicker recovery from outages
Project level build resources - allow for delegation of project-level administration
@MartynaWojtas is there any documentation / plans around getting apps approved for bamboo datacenter?
I am particularly curious if there is any plan to include bamboo in the performance testing framework.
For context, we have an app which is approved for Jira, Confluence and Bitbucket DC, and has a bamboo server version, and we are trying to plan what is required for this new release.
Edit: we were also curious if there are plans to publish cloud formation templates for Bamboo DC, like those available for other Atlassian DC products.
We are in a similar situation, so just two observations until we get an official response:
For anyone who hasn’t seen it, Martyna’s CAC post has a few more details regarding the Bamboo Data Center Apps Program coming soon which might be helpful to communicate the status to our mutual customers
We have been surprised about the flawed UPM compatibility handling as well, and given our analysis I’m afraid it simply doesn’t cover this foreseeable edge case of the Marketplace not yet supporting DC apps for a DC enabled host product - we have assessed various combinations of the DC compatibility markup and none seem to make any difference regarding the incorrect UPM message (there even seem to be a few subtle DC license state management bugs in UPM which I won’t go into here)
Thank you for your patience @richard.white, @michael.rueegg, @jeff - you’ve caught me during annual holiday. Thank you for providing the link to the CAC blog post @sopel! I’ll cross-post it to CDAC for better visibility.
Yes, DC Apps Program is in the works for Bamboo and it will be quite similar to other DC products. Once implemented it will be subject to the annual review.
We have been researching the cloud formation templates and are considering starting with a new approach for Bamboo DC Apps Program - terraform Kubernetes helm charts due to the rising interest in this type of deployment.
Bamboo Server applications will continue to work with Bamboo DC 8.0 until the certification process is implemented as we want to make sure all vendors have time to certify their apps.
We are aware that UPM lists Server applications as incompatible with Bamboo 8.0 (DC). As @sopel has mentioned, it’s an edge case - the DC product being available before the DC certification is ready. The warning doesn’t reflect the true state (for now Server apps are compatible with Bamboo DC), however we didn’t remove it to avoid a situation in which customers would use a version with the disabled warning after DC certification has already started. How big of an inconvenience it is for you and your customers? Will you be able to handle it for a few more weeks until the certification is ready?
@MartynaWojtas Thanks for the update! I think it is fine if it’s going to be a matter of weeks. It would be nice if this information would be linked on the Marketplace, maybe in a banner or so, to make it more accessible for the customers.
Please, for the love of all that is sacred in this world… DO NOT ADD ANOTHER TYPE OF STACK TO OUR ALREADY INSANE LIST OF THINGS THAT PARTNERS NEED TO DEAL WITH.
If you do decide to continue with this decision and add the additional burden of having to deal with Yet Another Toolkit, please note that we will have to reconsider adding support for Bamboo Data Center and/or will have to increase our list price to a point where we are royally screwing over our shared customers. Rest assured that we will list this as the sole reason why when communicating with our customers, letting them know that Atlassian actively decided to f*** them over, disregarding your core company value.
Most partners are meanwhile used to and mostly satisfied with performance and scale testing based on a unified framework that works similar across all products - it would really be a major burden if Bamboo would be the sole exception here (presumably not only for partners, but also for the DC Apps team, who would need to maintain another notably different set of tooling and instructions)
Many customers run their Atlassian stack in AWS, so given they can use the existing AWS Quick Starts for Jira/Crowd/Confluence/Bitbucket DC, having Bamboo DC readily available via the same architectural pattern would significantly reduce the operational burden for migrating to and maintaining Bamboo DC, and hopefully accelerate DC adoption in turn
I don’t know who is in charge of maintaining the official AWS Quick Starts, but from what I see it shouldn’t be a big effort for them to also provide a quick start for Bamboo, maybe you can delegate that to the resp. team?
It also wouldn’t necessarily need to be publicly available/supported right away, IIRC the Crowd quick start also lived only in the Atlassian GitHub organisation for quite a while, before being made officially available in the aws-quickstart GitHub organisation once matured.
@remie and @sopel are spot on. If you want to experiment with a new approach, can I suggest using the existing tried and tested way as a baseline and compare the results to that? Bamboo is already hard enough to develop for (in many dimensions e.g. technically, size of market) so making it more difficult only harms our common customers.
@MartynaWojtas any update on the Bamboo Data Center program? We’re still getting Add-on Update Request emails without any means to fix this. In addition, can you also please respond to our pleas to not diverge from the existing Performance Toolkit?
@remie@michael.rueegg@sopel@jmort thank you for sharing feedback and voicing your concerns! I’ve shared them with DC Apps and DC Deployments teams and we’ve been sparring and working on some solutions for the past few weeks. You may expect to hear from us soon - we intend to bring not only the answers but actually something to show for.
Forgive me for being a bit scared by this comment… normally, a decision precedes having something to show for, as the showing part requires putting in the hours. Not sharing that decision prior to showing something usually means that you made a decision that requires convincing others, one that cannot be reverted, or an effort to apply the sunken cost fallacy (we’ve already invested this much, it would be a waste to change it).
In either case, this probably means you’ve decided to go with the kubernetes solution.
Would you please be so kind to include the community in the decision making process? I’m sure we’re all technically versed enough to understand the implications without a demonstration.