Dev Tools – Atlassian Blogshttp://blogs.atlassian.com
Software development and collaboration toolsFri, 09 Dec 2016 14:12:58 +0000en-UShourly1https://wordpress.org/?v=4.6.1AtlassianDevToolsBloghttps://feedburner.google.comTry new merge strategies in Bitbucket Server 4.9 and morehttp://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/eSDzsQdFB7E/
http://blogs.atlassian.com/2016/08/new-features-bitbucket-4-9/#commentsTue, 30 Aug 2016 14:00:51 +0000http://blogs.atlassian.com/?p=35375Bitbucket Server 4.9 and Bitbucket Data Center 4.9 bring strategy to the forefront of how teams work with their source code. Learn about three new features and how your team and business can set up new strategies to help teams work the way they want to work.

]]>Bitbucket Server 4.9 and Bitbucket Data Center 4.9 bring strategy to the forefront of how teams work with their source code. Learn about three new features and how your team and business can set up new strategies to help teams work the way they want to work.

Make disaster recovery part of your business plan

For mission-critical tools like Bitbucket Data Center, disaster recovery (DR) is more than just a feature, it’s a strategy. Why? Because if the main instance goes down (aka a disaster) teams need a tool that allows them to continue working with their data. This is where DR comes into play. It provides Bitbucket Data Center customers the ability to replicate the state of their primary instances to a “cold standby” instance at an offsite location. So if your primary instance goes down, Bitbucket Data Center can cut over to the standby.

A “cold standby” is one example of a disaster recovery plan (DRP) in which the standby Bitbucket instances are cold and the file server, database and Elasticsearch instances are warm, in order for the replication to occur.

Since your standby site contains cloned Bitbucket indexes and a copy of your production database – think critical plugins – your team can quickly get back up and running. At Atlassian we use this model because we have instances in different geographies, so if a primary instance goes down in Sydney we can cut over to the disaster recovery standby instance in San Francisco with minimal downtime.

The addition of DR to Bitbucket Data Center gives teams and businesses the toolset to set up a proactive strategy for when things go wrong, so the prospect of developers sitting around with nothing to do becomes a non-issue. Instead admins and IT can focus on the reason for the downtime – no small feat – while source code work moves forward.

Choose how your pull requests get merged using merge strategies

While DR and zero downtime backup help teams and business with downtime strategies, Bitbucket Server 4.9 introduces a new feature specific to workflow and code review strategies called merge strategies. Its complement merge checks have been in Bitbucket Server for a while, but merge strategies give users and teams control over how pull requests get merged rather than controlling if a pull request can be merged.

Different teams desire different things when it comes to how they track the history of their repositories. Bitbucket has traditionally been opinionated about applying a merge commit when closing a pull request, but there are good reasons not to always do this. For example, some teams have a different view on what constitutes a clean history and want to use fast forward only or squash merge strategies.

►

Now a repo admin can define the default merge strategy and specify what alternative strategies are allowed for selection at merge time. That means the person merging each pull request can have full control over strategy used. An example where this can be handy is when you’re using a Gitflow branching model. You might set the default to squash on merge, but allow “no-ff” to be used so that proper merge commit occur between release branches. This detail in a team’s workflow, much like the default reviewers feature, gives teams unique features to work the way they want.

Import repositories from other hosting services

Lastly, starting a new project that requires a migration of repositories in bulk from one product to another or of repos from one server to another server should be frictionless. So instead of writing scripts or importing repos one at a time, the new import repository feature for both Bitbucket Server and Bitbucket Data Center allows for bulk imports to give teams the ability to try out real or demo data.

This is especially important when you’re just getting started with Git and Bitbucket Server, or wanting to pull in code from an existing project from Bitbucket Cloud, Github.com, GitHub Enterprise, or individually from any HTTP-based Git host. It is quick, easy, and gives teams the flexibility to work with data where they want to.

All of the new features released in Bitbucket Server 4.9 and Bitbucket Data Center 4.9 help teams collaborate with strategies in place. The addition of DR to Bitbucket Data Center is important to any team’s daily activities. Your tools are business and/or mission-critical, so work can’t be stopped during a disaster or downtime. And in the world of pull requests, different teams and different repositories may want to use different merge strategies.

The addition of merge strategies to your pull request workflow gives teams the flexibility needed to set up a merge strategy. It is with these types of features that Bitbucket Server and Bitbucket Data Center can help your team and business think about strategy at the team level and up to help teams work better together.

Check out the release notes for more information on these new features and the other improvements we’ve made in 4.9.

In case you missed it

Since Bitbucket 4.5 we’ve continued to improve our pull request experience, add new features, and more. Check out to see what has been added:

Code search shipped in Bitbucket Server 4.6. You can now search for code directly in the search bar, which includes searching code across all of your projects and repositories. Or you can get more granular to search for code in a specific project or repository. And you have the option to use search operators to get more precise search results and can search for code on the language it’s written in.

Commit-level review shipped in Bitbucket Server 4.8 to provide per-commit diff views and commenting within pull requests to help reviewers do just that – review individual commits added to a pull request. Highlighting changes at this granular level makes the reviewing experience better for every member on the team and will result in faster pull request turnarounds.

Default reviewers shipped in Bitbucket Server 4.8 to give teams the option to configure a default set of reviewers that will be pre-populated on the pull request creation form on any given repo. Default reviewers can even be defined by source and target branch, and once it’s set up you can add or remove people from the list as needed.

Bitbucket Data Center now offers source code collaboration for teams at the 25 user tier. Learn about what features you get when you switch to Bitbucket Data Center including smart mirroring, Git LFS, and more.

]]>http://blogs.atlassian.com/2016/08/new-features-bitbucket-4-9/feed/6http://blogs.atlassian.com/2016/08/new-features-bitbucket-4-9/Bitbucket Data Center is now available for growing teamshttp://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/rx1byu6XT7Q/
http://blogs.atlassian.com/2016/08/bitbucket-data-center-is-now-available-for-growing-teams/#commentsTue, 02 Aug 2016 14:00:58 +0000http://blogs.atlassian.com/?p=35212Bitbucket Data Center is a next generation Git solution. Whether you're burning the midnight oil at a startup or starting a new project within a larger organization, we want to be part of your Git journey. To do that, we need to be there from the start. That's why Bitbucket Data Center now offers source code collaboration for professional teams, across any distance, whether your team is small or large. Keep reading to learn more about what Bitbucket Data Center can offer any team.

]]>Whether you’re burning the midnight oil at a startup or starting a new project within a larger organization, we want to be part of your Git journey. And in order to do that, we need to be there from the start. So Bitbucket Data Center now offers source code collaboration for professional teams, across any distance, whether your team is small or large.

Keep reading to learn more about what Bitbucket Data Center can offer any team, and how you can grow with Atlassian products.

Bitbucket Data Center is a next generation Git solution

When tools are mission critical to your work, you can’t afford any downtime. It doesn’t matter if your team is made up of 25 or 2,500 people; what matters is that your team can do what needs to be done without worrying about outages. This makes a deployment option like Bitbucket Data Center the solution for teams of all sizes and working together across the globe.

For example, if your Git solution gets hit with multiple users and clients (think CI/CD) then you need a highly available tool. Bitbucket Data Center is the only Git solution with out-of-the-box active-active clustering, which provides uninterrupted access to your source code even during an unexpected outage with zero downtime.

For distributed and/or large teams, Bitbucket Data Center provides features like smart mirroring and Git LFS (Large File Storage) to help with performance. Let’s look at a team at Atlassian that fits this bill. The JIRA Software team has teams located in Sydney, Australia and Gdansk, Poland. In a typical workday it’s common for a developer in Gdansk to need access to a repository hosted in Sydney. Instead of having to wait hours to clone the repository, the developer in Gdansk can clone and create a branch from the mirror that we have set up in Gdansk within just a few minutes because of our Git mirroring. By speeding up clone times, our teams aren’t worried about lost development time and can work more efficiently across countries and continents.

Git LFS, on the other hand, is meant for teams that work with large media assets like images and videos. At Atlassian Git LFS helps our designers, tech writers, and build engineers to be more productive when working with developers, because assets can be versioned in Bitbucket Data Center. This means that developers don’t need to shoulder tap or leave their code when working with assets like videos or audio files, because they have the information they need to make exceptional UI experiences at scale. As software development moves more and more into the direction of distributed agile development and even into the land of apps that require large files and slick designs, it’s a necessity for tooling to support various ways of working.

Bitbucket Data Center offers the only solution with default reviewers

Reliability is not the only reason why teams can grow with Bitbucket Data Center. It’s a combination of using highly available tools and features that help teams move fast. A small team might be tired of hearing “We need to move faster,” and a mid-size team might feel the pains of “Our team is growing and we need a more sophisticated way to manage our source code.” Wherever you fall on this spectrum of size, everyone should have the same access to features that help them get what needs to be done, done.

Pull requests are a great example of a feature in Bitbucket Data Center that help teams innovate, because they’re set up to yield quick turnaround times for code reviews and help teams ship faster and deliver value quickly to customers. Pull requests are also set up to include default reviewers and commit-level review. The commit-level review, for example, shows comments within a pull request, so reviewers can see what changes are being made through a code review.

But pull requests are not the only feature built around teams and collaboration. At Atlassian, smart commits give developers the ability to transition JIRA Software issues by embedding specific commands into a commit message from the source code. Developers also use code search to search code to find exactly what they’re looking for, right from the search bar. Pull requests, smart commits, and code search are especially important as your instance, project, and teams grow to keep organized and moving quickly.

Bitbucket Data Center integrates and can be built upon

Besides high availability and features that help growing teams collaborate, Bitbucket Data Center can act as a development platform by setting up integrations. If your team uses existing Atlassian tools, like JIRA Software and Bamboo, you can set up Bitbucket Data Center with these tools for full traceability and continuous integration or continuous delivery.

The Atlassian marketplace, offers hundreds of add-ons to meet your team’s needs outside of integrations with Atlassian tools. Integrations are important to any team and a Git solution needs to support end users, Applinks with other Atlassian tools, API calls, and/or WebHooks without slowing down response times. So the sheer number of end users becomes only one part of a larger story of your greater ALM solution (Application Lifecycle Management) no matter how small or large your business is.

By adopting Bitbucket Data Center as a small team, from day one, you are working with a solution designed for professional teams and rooted in team collaboration. This tool is also now meant to grow with your business as your team grows, wherever you are in the world.

]]>http://blogs.atlassian.com/2016/08/bitbucket-data-center-is-now-available-for-growing-teams/feed/2http://blogs.atlassian.com/2016/08/bitbucket-data-center-is-now-available-for-growing-teams/The (written) unwritten guide to pull requestshttp://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/srg8CHcsARw/
http://blogs.atlassian.com/2016/07/written-unwritten-guide-pull-requests/#commentsMon, 25 Jul 2016 13:00:09 +0000http://blogs.atlassian.com/?p=35091Code review is also one of the most difficult and time-consuming parts of the software development process, often requiring experienced team members to spend time reading, thinking, evaluating, and responding to implementations of new features or systems. To help your software development team empty those "In review" columns more quickly, here are some guidelines for your pull requests from a variety of different developers at Atlassian:

]]>Code review is a very important part of the software development cycle. In Bitbucket and other source code management systems, pull requests are used to review code on branches before it reaches master. Code review is also one of the most difficult and time-consuming parts of the software development process, often requiring experienced team members to spend time reading, thinking, evaluating, and responding to implementations of new features or systems.

It’s no surprise that endless “In review” columns on agile boards is one of the most common issues raised by software teams (including at Atlassian!) during sprint retrospectives.

To help your software development team empty those “In review” columns more quickly, here are some guidelines for your pull requests from a variety of different developers at Atlassian:

I’m sure the size of that “in review” column is familiar to many-a-team.

Reviewing pull requests is hard

First, let’s admit it: reviewing pull requests is really hard. As a reviewer, it’s your responsibility to make sure that the code is correct and of high quality before it gets merged into master. You are expected to do that by looking at a diff and list of files changed. You have to understand what the pull request is trying to achieve, what approach is being taken, what’s going on, and how all these files fit together – enough that you could potentially suggest an improvement. You may have to be on the lookout for typos or style problems. That’s a LOT of stuff a reviewer needs to do, especially in a large pull request!

How can we make our pull requests easier for our reviewers?

Let’s put on our product management hat. If pull requests are a product, then reviewers are our customers. We want our customers to ‘buy’ our pull requests by approving them so we can ship quickly and empty that review column. If we are to manage this product well, one thing we need to do is understand our customers and market. It’s pretty simple, really. Since most of us pull request authors have likely been reviewers already, simply put yourself in the shoes of the reviewer and ask, “How could this be easier for me?”

Make smaller pull requests

Making smaller pull requests is the #1 way to speed up your review time. Because they are so small, it’s easier for the reviewers to understand the context and reason with the logic. Now, you may be thinking:

But Blake, my issue just exploded in complexity after I started working on it.

Trust me, I’ve been there. It’s really easy to throw yourself into finding the solution to the problem you’re working on and lose focus on the bigger picture. Unfortunately, in my experience, solving the issue usually represents a surprisingly low portion of the time spent between ticket creation and release to customers. Review, quality assurance, and the release process all take time. Spending a bit more time breaking down the problem while you’re actually problem-solving is worthwhile, especially when your team is dealing with endless review columns.

I have no way to tell whether a pull request is going to be big until I start on an issue, at which point it’s usually too late.

It’s easy to make big pull requests. It’s difficult to make small, logical ones that are quick to review, push, and achieve velocity with. On my team, we are experimenting with small, time-boxed spikes on issues we pick up to see if we should break them down any more before pushing any code. We’ll see how that goes, but in the meantime, it’s definitely worth time breaking down your tickets or pull requests before you commit them in one massive push.

Write useful descriptions and titles

Writing a useful description in the “details” section of your pull request can almost be as effective as making a smaller pull request! If I do make a large pull request, I’ll make sure to spend a lot of time making a really helpful description. The best descriptions guide the reviewer through the code as much as possible, highlighting related files and grouping them into concepts or problems that are being solved.

This saves the reviewer a lot of time because they don’t have to read every file to try and group them up and identify related concepts. After that, it’s a lot easier to reason about and review your approach. The pull request author is the best person to do this since they made these files in the first place, and have all the details fresh in their minds. Similarly, a useful summary title (instead of just the issue key) makes it clear to the reviewer what’s being solved at a high level, which takes off one extra step for the reviewer. At the end of the day, both of these things give the reviewer more context around the change that’s happening.

Have on-point commit messages

“addressed PR feedback” -> a very common but not-so-useful commit message.

I don’t expect everyone to have every line of their Git commit messages down to a strict 72-character limit, (although the first 50 characters are useful as a summary), but a good commit message can help improve a code reviewer’s experience. First, they can make Bitbucket’s auto-generated pull requests more useful, especially for smaller pull requests. Good commit messages can also provide a nice bullet-point-like summary of the code changes as well, and it helps reviewers who read the commits in addition to the diff.

I’m a bit guilty of lower-quality commit messages. That said, commits are very much at the code-level, and should be about the code changes. A pull request, on the other hand, though it is code-focused, requires a higher-level, architectural understanding of the change. A high-level summary and understanding of the problem is very useful for people looking back through a repo’s history in addition to reading the details of the individual code changes. For this reason, I’m very much a proponent of putting a JIRA issue key in every commit message, so no matter where a user finds a commit message, there will always be a trail back to the pull request. This also helps soften the blow of lower-quality commit messages.

Even if you have completely on-point commit messages, I still believe in writing a good description in the pull request over only using the auto-generated commit log. As I said before, commits are very much at the code-level while code review requires a higher-level understanding of the change, and that’s hard to achieve with a commit message log alone.

A colleague gave me really nice summary of how to think while writing commit messages:

Commit message should talk about WHAT changed, and WHY. Not HOW – how is the diff, and you don’t need to repeat it.

Add comments on your pull request to help guide the reviewer

Have you simply re-indented lines in one file? Is a particular file the “main bulk” of your change? Is a file related to, or coupled with, another in the same pull request? Consider leaving a comment inline, at the top of the file, to let the reviewer know. These help the reviewer navigate your pull request.

Even better, it’s possible to create a pull request with no reviewers, allowing you to review it yourself and write comments pointing out the interesting bits before anyone else sees the code.

It’s worth noting that pull request comments should not be used to explain your code. If you find yourself explaining your own code in a pull request comment, consider making it an actual, in-code comment instead. These comments are only for helping the reviewer navigate your pull request.

Make it visual

Add some screenshots for your front-end changes! Screenshots simply make the job for the reviewer much easier. It’s easier to reason about front-end changes when you can visually see what’s been changed in the pull request. If you’re feeling extra generous, add a GIF or video of you using the feature (potentially in multiple browsers, if that’s important) to add some extra validation for your UI changes.

Also, consider adding your designers to pull requests for front-end changes. They can often spot visual quirks, as well as copy mistakes, earlier in the process thanks to the screenshots!

Wrapping up

These are just some of ways to write pull requests to improve the pull request experience for reviewers around your company.

If you start thinking of a pull request as a product, with the author as the seller, and reviewers as customers, then that helps you understand your “customer” in order to “sell” your pull request more effectively and get faster approvals.

Though this is how I think about pull requests, I want to emphasize that these are just guidelines, not hard and fast rules. Please feel free to comment below with your own techniques for keeping your PR column under control and share your pull request experiences – I’d love to hear how your team handles code review!

Hopefully, together we can create better pull request and code review experiences for everybody.

Speaking of pull requests, we just upgraded our PR review process in Bitbucket to help you keep all your PRs in one place. Learn more about the update on the Bitbucket blog or sign up for free.

]]>http://blogs.atlassian.com/2016/07/written-unwritten-guide-pull-requests/feed/16http://blogs.atlassian.com/2016/07/written-unwritten-guide-pull-requests/3 new features in Bitbucket Server including commit-level reviewhttp://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/7kW4IkAQn1Q/
http://blogs.atlassian.com/2016/07/new-features-bitbucket-4-8/#commentsTue, 19 Jul 2016 14:00:50 +0000http://blogs.atlassian.com/?p=35062Three new features released in Bitbucket 4.8 provide teams with Git best practices and make collaboration easier. Whether you're the reviewer of a pull request or need to assign a reviewer, the two new pull request features make code reviews easier for quick turnaround times and better quality code. And zero downtime backup provides an active recovery mode so work is not put on hold and collaboration doesn't need to come to a halt when you're dependent on clients or team members in different timezones. Through these features teams can make sure teammates stay close to (working) code to produce higher code quality.

]]>Bitbucket Server 4.8 is all about faster turnaround time for pull requests and zero downtime backup. Keep reading to learn about three new features and how each one helps teams collaborate to produce higher quality code.

Break down big or long-running pull requests with commit-level review

Pull requests make collaboration easier for developers wherever and whoever you are in the code review process. Plus, they help teams follow best code review practices by including specified reviewers in the workflow. But what if you’re the reviewer and you would like to review individual commits added to a pull request quickly?

The new commit-level review provides per-commit diff views and commenting within pull requests to help reviewers do just that – review individual commits added to a pull request. For example, if a pull request author has thoughtfully broken down their work into logical commits, you can now step through the changes for each commit. And at any time the effective diff for the whole pull request is still available for the “big picture” view.

Commit-level review is also really handy when returning to a pull request that you’ve already reviewed. You can see how your feedback has been incorporated without having it mixed up with changes you’ve already seen, because commit-level review allows you to view and comment on individual changes, one at a time. Highlighting changes at this granular level makes the reviewing experience better for every member on the team and will result in faster pull request turnarounds.

Set up default reviewers for pull requests

The focus on commit-level review in Bitbucket Server 4.8 is no coincidence, because pull requests are at the heart of workflows in Bitbucket. Along with reviewing pull requests, adding a reviewer should be easy. But not all teams have a frictionless process for assigning reviewers.

For example, do you have a release gatekeeper on your team that reviews or merges every pull request? Or are you on a small team and everyone is asked to review each pull request? What if you’d like to avoid building up a list of reviewers from scratch for every pull request? With the new default reviewer feature, on any given repo you can configure a default set of reviewers that will be pre-populated on the pull request creation form. Default reviewers can even be defined by source and target branch, and once it’s set up you can add or remove people from the list as needed.

In addition, a new merge check is available for specifying that a certain number of these default reviewers must approve before a merge can occur. By setting up these checks, you can make sure the release manager gets a heads-up on pull requests targeting release branches, the senior dev approves all changes to the default branch, and the bug-master reviews all the bug fixes. This granularity of configuration by branch is a powerful tool and is one of the many ways that the pull request experience is unique to help your team be innovative.

Back up data without downtime

Backups are business as usual for any company that relies on hosted software. An important aspect of backups is making sure that consistent copies of data are made using supported mechanisms, and that has meant some amount of regular downtime. If you have builds that run at night and the downtime happens at night, then your builds will fail. If you have teams halfway around the world, then your nighttime is their daytime, resulting in downtime during their working hours.

In Bitbucket Server and Bitbucket Data Center 4.8, it’s now possible to create a backup without locking or shutting down the instance to reduce downtime due to backups. As long as your file system and database snapshots are each consistent within themselves (various vendor-supported options exist for each) a restore where the snapshots aren’t in sync with each other will now result in a working instance that’s tolerant to minor inconsistencies where operations occurred during the backup period.

In addition, Bitbucket Data Center has an active recovery mode that can be run on start-up to find, log, and resolve any inconsistencies between filesystem and database. The addition of zero downtime backup to active-active clustering in Bitbucket Data Center is another way to ensure constant access for users.

All of the new features released in Bitbucket Server 4.8 provides teams with Git best practices and make collaboration easier for teams. Whether you’re the reviewer of a pull request or need to assign a reviewer, the two new pull request features make code reviews easier for quick turnaround times and better quality code. The same can be said for zero downtime backup: with an active recovery mode, work is not put on hold and collaboration doesn’t need to come to a halt whether you’re dependent on clients or team members in different timezones. It’s through these features that teams can make sure that team members stay close to (working) code to produce higher code quality.

Testing is fundamental to the life of a software developer. The more code you write, the more testing it requires. The more testing you employ, the more important automation becomes. The more automation you leverage, the more infrastructure you need. And of course, more infrastructure means more cost. A yin for every yang. In software, as in life, there’s always a balance.

To develop is to test. If Confucius wrote code, that’d be his mantra.

But what if we could tip the scale in our favor? Maximize our investment in automated testing, while minimizing our cost of infrastructure. Sounds impossible, right? Well, not only is it possible, we’re already doing it here at Wittified, and I’m excited to show you how!

Tipping the scale

Once your code base grows to a certain point, automation becomes a requirement for testing. If your product integrates with another system, then integration testing is another requirement. And those integration tests typically require a test harness and/or dedicated servers (which often need to be reset between test runs).

At Wittified, we currently develop over 20 products. At that volume, having a dedicated server sitting around for each product wasn’t efficient.

Enter the art of Infrastructure as a Service (IaaS).

There are several IaaS providers out there, but our current favorite is Digital Ocean. If you’d like to try them out and follow along with our walkthrough, feel free to use our referral code and save some bucks: https://m.do.co/c/910721bc1503

For each basic platform we want to test on, we create a new Digital Ocean “Droplet” (their name for a server). We configure the Droplet as needed, then shut it down and create a snapshot. We repeat this flow for each basic platform combination.

This enables us to quickly spin up a new instance whenever necessary to do some quick testing against a real platform configuration.

On their own, these snapshots can be a major time saver, but the biggest value comes when we make the leap into automated testing. There’s an awesome command line tool for Digital Ocean called Tugboat that allows you to interact with Droplets through scripts. Leveraging Tugboat in conjunction with a few wisely placed Bamboo Jobs (see below), we’re able to automate the creation of new test servers, and once we’re done, easily destroy them.

So how do we actually do this? To demonstrate, let’s test an example JIRA add-on against all minor versions of JIRA from 6.0 to 7.0.

1. Spinning up of the Droplet using Tugboat, and generating a “droplets.properties” file.
2. Reading the IP from droplets.properties, using: Bamboo Inject Variables Plugin
3. Executing our tests using the IP in step 2.
4. Killing the Droplet once complete.

Wait a minute. Doesn’t that mean we’re going to have image id’s spread out across all of our build jobs? Nope. Bamboo to the rescue! We’ll just use Global Variables to centralize them. This enables us to easily upgrade our test data by creating a new snapshot and then simply updating a Global Variable.

You might say, cool, but what’s the point? Why not just have the necessary servers always up, ready, and waiting for our tests? The answer is pretty easy: Cash. Rather than paying good money for a server that’s just sitting there whether it’s active or not, each build can now automatically trigger a new server whenever it needs one, and then effortlessly kill it once complete. We also no longer have to worry about multiple builds colliding with each other. Every build always gets its own server to test against.

Pay less, get more. Now that’s a mantra to live by!

Priorities

So where do we go from here?

Since we live in a world of fast feedback, the next step is to prioritize our builds. First we run our unit tests and basic integration tests which don’t rely on any server resources. Then by using Bamboo‘s Stage functionality we automatically test against the “most important” version of JIRA (our host product for this example) after the quick tests have finished. This version is often the latest, or the one being used by most of our customers. This allows us to quickly test the waters and gain a bit of comfort with each build before proceeding against all intended versions. Using the Manual Stage functionality creates a gate before executing our tests against the remaining versions of the host product we support. This gate allows the developer to receive fast feedback, and thus specify when the tests should be run against all of the remaining supported versions. While it is a manual step, using this approach allows us to reduce the noise of preventable failed builds. In addition, the entire team can easily see the health of the build without having to look in multiple places. As I always say, an efficient developer is a happy developer!

And you know who else is happy? Finance and management. That’s because server resources can now be tracked right down to the individual build. And because Digital Ocean’s charge model supports billing based upon hourly usage, you know you’re always getting the most for your money. For JIRA testing, our per-version cost is usually about $0.03, which is pretty low. Even as it applies to our User Limit Manager add-on for Confluence (with up to 60 independent servers testing against all kinds of variables like LDAP, Crowd, and more) our total cost is only about $2.00. That’s an impressively small price, for an enormous benefit — automated validation that our code is doing what it’s supposed to do.

Walking the path

If you’re looking for a lean and nimble strategy to scale your Continuous Integration infrastructure, this is the path I recommend. The rest is up to you. As with any new journey, just take it one step at a time and feel free to use the examples above. As Confucius may or may not have said: “I hear and I forget. I see and I remember. I do and I understand.” In other words, let’s get testing!

Did you find this post useful? Share it on your social network of choice so others can conquer their CI infrastructure!

]]>http://blogs.atlassian.com/2016/07/conquer-your-ci-infrastructure-continuous-integration-thats-lean-and-nimble/Bitbucket Server 4.7: Improved APIs for managing pull request restrictionshttp://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/GijgdqkUzM0/
http://blogs.atlassian.com/2016/06/bitbucket-server-4-7/#commentsTue, 21 Jun 2016 13:00:38 +0000http://blogs.atlassian.com/?p=34898As software organisations grow it becomes difficult to ensure development rules and workflows are enforced across all teams and projects. With the release of Bitbucket Server and Bitbucket Data Center 4.7, we've made improvements to our REST and Java service APIs to make it easier for large software teams to make sure their rules and workflows are actually being followed – automatically.

]]>As software organisations grow it becomes difficult to ensure development rules and workflows are enforced across all teams and projects. With the release of Bitbucket Server and Bitbucket Data Center 4.7, we’ve made improvements to our REST and Java service APIs to make it easier for large software teams to make sure their rules and workflows are actually being followed – automatically.

REST and Java service APIs to manage pull request restrictions

While automation is used to keep projects consistent, at the same time each organisation is also a little bit different so there isn’t necessarily a “one size fits all” solution. This is where external tools and scripts can step in and call on Bitbucket Server’s APIs to apply whatever business rules are required.

In 4.7 we’ve closed an important gap in coverage for these kinds of operations by adding REST and Java service APIs for setting pull requests restrictions. Now, in addition to being able to remotely create a repo and set up branch permissions, you can specify the minimum approvals and successful builds required for a pull request to be mergeable. For our 3rd-party developers writing similar merge checks, we’ve also made it possible for your own add-ons to expose a consistent API.

These API improvements are just the tip of the iceberg. This release addresses over 400 votes on our public issue tracker, so let’s take a look at what else is new:

Add or delete tags to commits from the web UI

Tags in Git let you mark a particular point in your commit graph such as an important build or release. It’s always been possible to do this via Git, and we previously added the ability to do it via the REST API, but lots of people were asking for a way to do it from the comfort of the Bitbucket UI. In 4.7 that’s possible, so you don’t have to switch to your Git client just to create a tag on a commit.

Improvements for raw file URLs

Previously our raw files were served by adding “?raw” to a file URL. This didn’t work so well when people wanted to use links in other files in the repository. That URL scheme still exists, but to address the issue we’ve introduced a new URL scheme that works for relative linking purposes.

Check out the release notes for more information on these new features and the other improvements we’ve made in 4.7. Ready to update to this release? Let’s get to it.

]]>http://blogs.atlassian.com/2016/06/bitbucket-server-4-7/feed/4http://blogs.atlassian.com/2016/06/bitbucket-server-4-7/Quick filters, improved user management & more in Bamboo 5.12http://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/9KzQWu2ynU8/
http://blogs.atlassian.com/2016/06/quick-filters-improved-user-management-bamboo-5-12/#commentsTue, 14 Jun 2016 13:00:24 +0000http://blogs.atlassian.com/?p=34811Knowing that many of our customers have very large and growing instances with hundreds to thousands of projects and plans, we have improved filtering and search so that Bamboo stays a world-class enterprise solution with more options for all users. Additionally, we’ve added an extra option for easier user management without tool-switching. Read on to learn more about all we have for you in this release.

]]>Search is one of the most valuable features in today’s software world. Being able to quickly find relevant information through thousands of lines of code, or hundreds of agile boards, build plans, and tests is a necessity for staying speedy and efficient. Without access, content is useless.

Knowing that many of our customers have very large and growing instances with hundreds to thousands of projects and plans, we have improved filtering and search so that Bamboo stays a world-class enterprise solution with more options for all users. Additionally, we’ve added an extra option for easier user management without tool-switching. Read on to learn more about all we have for you in this release!

Handy search shortcuts for your dashboard

The single filter per user is now improved to “Quick Filters”. Quick filters enable users to have multiple, more advanced filters so you can get easier access to what you need and search through your plans faster. These search shortcuts in your Bamboo build dashboard allow you to create filters based on configurable rules.

New user management option & more!

No more moving to Crowd to disable users. In this new release, we have a new user management option that allows you to deactivate users from within Bamboo. It’s as easy as finding the user under the user management screen and unchecking the “Active User” checkbox. Deactivated users won’t receive any notifications and can no longer log in to Bamboo.

Last, but not least, we’ve added support for yet another database: PostgreSQL 9.5.

Regardless of if you’re in early stages of continuous delivery, or operating on more advanced levels, Bamboo has all you need to grow with you. You can start with Bamboo by creating a simple plan sitting on your local Git repository or configure a multi-stage plan with dependencies and auto-triggered deployments projects. Try it for free if you are looking for a strong continuous integration software, or upgrade to 5.12 and benefit from all enhancements and new features.

]]>http://blogs.atlassian.com/2016/06/quick-filters-improved-user-management-bamboo-5-12/feed/4http://blogs.atlassian.com/2016/06/quick-filters-improved-user-management-bamboo-5-12/Bridging the gap between content and design with wireframeshttp://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/En7JGwsIv-A/
http://blogs.atlassian.com/2016/05/bridging-gap-content-design-teams-wireframes/#commentsTue, 31 May 2016 13:00:40 +0000http://blogs.atlassian.com/?p=34699We all know that the success of any project hangs on having the right teams and processes in place. But sometimes, this can feel like an unreachable goal when it comes to the day-to-day of project management. However, establishing common techniques for communicating and transitioning assets can smooth out this process and create a better experience for everyone involved. One of these techniques centers around creating wireframes, or rough visualizations of a concept or user interface.

This is a guest post by Leon Barnard, writer and designer for Balsamiq, creator of rapid, fun, and effective wireframing software

We all know that the success of any project hangs on having the right teams and processes in place. But sometimes, this can feel like an unreachable goal when it comes to the day-to-day of project management.

For instance, on a marketing team producing work that spans a variety of disciplines like content, design, and operations, it can be difficult to collaborate effectively across teams. Everyone has experienced this at some point: Work is planned and handed off from one team to another, only to be delivered with surprises or missing elements.

However, establishing common techniques for communicating and transitioning assets can smooth out this process and create a better experience for everyone involved. One of these techniques centers around creating wireframes, or rough visualizations of a concept or user interface.

Wireframes are crucial to ensuring that all the elements of a particular project are in place and working with each other. Here are two ways that the use of wireframing has helped teams bridge the gap between content and design.

Wireframing to avoid the design gap

Words are powerful. The story you tell about your product can make it stand out, or fall flat. And your story is about more than just the words you use. It’s about how you tell it, which often includes images, video, or illustrations. Content and design work together in perfect harmony.

However, content strategist, John McGarvey, has discovered a “design gap” that occurs between content creators and designers that often stands in the way of this harmony. He describes it this way:

“The ‘design gap’ happens when a designer and writer work on the same project, but don’t communicate with each other. I think the most visible symptom is when too much lorem ipsum starts appearing in mockups, or when bringing the content and design together results in a jumbled mess that doesn’t quite make sense. Design provides context that makes the content more understandable. Basically, content and design are closely linked. If the two don’t complement each other, you end up with a mess.”

John uses wireframes to collaborate with his designers on web content because it allows them to pass work back and forth using a tool they are both comfortable with. It helps him and his team understand what works and what doesn’t, and test prototypes with real users.

But John isn’t the only content writer who feels this way. Glenn Murray, a copywriter, talks about a “WYSIWYG” approach to content writing. “WYSIWYG” is an acronym that means “What you see is what you get”, meaning that deliverables resemble the final product, rather than text in isolation.

Here’s an example of one of his WYSIWYG wireframes:

Wireframing to get better feedback

Sometimes it’s better to attack a problem by working backwards. To find the best design for a particular project faster, some teams use wireframes for rapid idea exploration and iteration at the outset of a project. Just as A/B testing allows you to test multiple concepts, wireframes allow you to try out visual treatments, get feedback on them, and then make changes.

It’s about being responsive and getting input from others, instead of making plans in a vacuum.

While working on some banner ads for a Balsamiq campaign, we created some mockups to try out ideas for both the text content and the visual layout. We sent these concepts out the team, and were more quickly able to narrow down the right direction for the ads than if we had presented one single option and asked for feedback.

Rather than just putting together a design and getting a few “looks good to me” replies, presenting several ideas starts a conversation. And the “rough” feel of wireframes makes them feel temporary, even and invites more critique than something that looks “complete” would.

Effective communication, while hard to measure, and therefore often overlooked, is as much a key ingredient to project success as the quality of the contributors. The gaps between roles in a marketing project can be bridged with visual communication tools, such as wireframing software, that are designed to be usable by a broad range of people. The result is a better overall product and more participation and feeling of inclusion from team members.

For more on project collaboration best practices for marketers, see some of our recent marketing blog posts. And, to learn more about Balsamiq wireframes offered for JIRA and Confluence, visit the Atlassian Marketplace.

]]>http://blogs.atlassian.com/2016/05/bridging-gap-content-design-teams-wireframes/feed/1http://blogs.atlassian.com/2016/05/bridging-gap-content-design-teams-wireframes/Bitbucket Pipelines Beta: continuous delivery inside Bitbuckethttp://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/8peN2MShB58/
http://blogs.atlassian.com/2016/05/introducing-bitbucket-pipelines-beta-continuous-delivery-built-within-bitbucket/#commentsTue, 24 May 2016 09:57:15 +0000http://blogs.atlassian.com/?p=34595Bitbucket Cloud is introducing Pipelines to let your team build, test, and deploy from Bitbucket. It is built right within Bitbucket, giving you end-to-end visibility from coding to deployment. With Bitbucket Pipelines there's no CI server to setup, user management to configure, or repositories to synchronize. Just enable it in one click and you're ready to go.

]]>
Software has changed the world faster than almost any other industrial innovation and it’s only picking up speed. Companies are moving from infrequent, large code deployments to frequent, small, and agile deployments. This trend is having a huge impact on current software development processes. For example, in one of our most recent customer surveys, more than 65% of software teams noted that they are practicing some form of continuous delivery. It’s becoming the norm for software teams.

But implementing continuous delivery is not easy. Setting up build agents is complicated. Developers have to constantly juggle between different tools. And most of the time, the build is sitting in a queue, or you’re burying yourself in log files digging for information about failures.

Bitbucket Pipelines

Until now. Bitbucket Cloud is introducing Pipelines to let your team build, test, and deploy from Bitbucket. It is built right within Bitbucket, giving you end-to-end visibility from coding to deployment. With Bitbucket Pipelines there’s no CI server to setup, user management to configure, or repositories to synchronize. Just enable it in one click and you’re ready to go.

It’s all Bitbucket: Manage your entire development workflow within Bitbucket. No need for a separate tool.

Instant setup: You can create and run your CD pipeline once you sign up for Bitbucket. No agent configuration required.

Fast feedback: We show build statuses automatically everywhere you care about them – on branches, commits and pull requests.

Self-service for teams: Build configuration stored as code and out-of-the-box Docker support helps teams be independent.

Pipelines is also a great fit for branching workflows like git-flow. Anyone on your team can adapt the build configuration to map the structure of your branches. Here is a quick look at some of the salient features of Bitbucket Pipelines:

Bring your own services to Bitbucket Pipelines

We worked very closely with some of the leaders in the industry so you can bring your own services to Bitbucket Pipelines, right out of the box. Whether you want to deploy, test, monitor code quality, or store artifacts, complete any workflow with the tool of your choice: Amazon Web Services, Ansible, bitHound, BrowserStack, buddybuild, Code Climate, JFrog, Microsoft Azure, npm, SauceLabs, Sentry, Sonatype, and TestFairy.

“Pipelines provided us with the perfect opportunity to bring the power of automated code quality analysis to Bitbucket users. We’re excited about the awesome potential of Pipelines and they’re only just getting started!” –Michael Bernstein, VP of Community, Code Climate.

Continuous Delivery options from Atlassian

We believe that the best way to provide our customers with a top-notch cloud CD solution is to build the service natively within Bitbucket Cloud. That’s why we built Bitbucket Pipelines and also why today, we’re announcing the end-of-life for Bamboo Cloud, which will be discontinued starting Jan 31, 2017. While Bamboo Cloud has helped many customers to adopt CD, we realized that we would not be able to deliver the experience and the quality of service that our customers need. If you’re a Bamboo Cloud customer, click here to learn more about the migration options.

If you want to build and ship behind the firewall, we’re still heavily investing in Bamboo Server as an on-premise CD solution.

Get early access to Bitbucket Pipelines

With Bitbucket Pipelines we want to empower every team to accelerate their releases. No more time wasted on setup and maintenance, just focus on the work you love. You can sign up for Bitbucket Pipelines Beta today and request early access.

]]>http://blogs.atlassian.com/2016/05/introducing-bitbucket-pipelines-beta-continuous-delivery-built-within-bitbucket/feed/44http://blogs.atlassian.com/2016/05/introducing-bitbucket-pipelines-beta-continuous-delivery-built-within-bitbucket/Search your code with Bitbucket Server 4.6http://feedproxy.google.com/~r/AtlassianDevToolsBlog/~3/2R_IKNj5CFM/
Mon, 16 May 2016 13:00:37 +0000http://blogs.atlassian.com/?p=34534Having the right information available at the right time is key to sustaining the speed and efficiency of software development. And with the goal to improve software development for teams everywhere, we’ve released Bitbucket Server and Bitbucket Data Center 4.6 to help your teams release faster and more efficiently. This release addresses feature suggestions with over 500 votes on our public issue tracker. Here are some highlights: Code Search We announced code search back in April and we’re proud it has graduated from our Early Access Program and is now generally available for Bitbucket Server and Bitbucket Data Center. Searching for code is a highly requested feature by our users, and for good reason – as the amount of code you have inevitably grows, it can be tough to find exactly what you’re looking for. In 4.6, you can now search for code directly from the search bar, and also: Search for code across all your projects and repositories. Search for code within a specific project or repositories. Use search operators to get more precise search results. Search for code based on the language it’s written in. Commit message and timestamp in source view When browsing a repository it can be useful to understand information about the latest change to a file to help guide you on your way. To help with this, the file browser now includes details of the last commit for each file, just like in Bitbucket Cloud. In addition, hovering over the commit will display the full commit message. This is a handy little interaction we’ve sprinkled into other pages too, such as the commit list and blame views. Blame in diff view Speaking of which, blame views are now available in more places. You might be familiar with the blame button in the source views. It’s based on the git command of the same and shows details of the last commit line-by-line. It’s great for chasing down bugs. Now, the blame view is available in diff views too, so a commit diff or pull request diff can tell you more about the nature of the changes you’re looking at and where they came from. For example, you can find out who last changed some code and then bring them into a pull request for an expert perspective by mentioning them in a comment. TL;DR: Stay. In. Flow. But wait, there’s more! Gone are the days of confusing timestamps; we’ve added the ability to set your individual time zone. Now remote users and distributed teams can set their own time zones, providing accurate local timestamps within the interface and notification emails. Admins can set the default time zone of the primary instance, but it won’t override a user’s preference. Check out the release notes to read more about these new features and the other improvements we’ve made in Bitbucket Server and Data Center 4.6, or update now. Update to Bitbucket Server 4.6 Did you find this post useful? Share it on your social network of choice so your fellow Bitbucketeers can learn about the […]

]]>Having the right information available at the right time is key to sustaining the speed and efficiency of software development. And with the goal to improve software development for teams everywhere, we’ve released Bitbucket Server and Bitbucket Data Center 4.6 to help your teams release faster and more efficiently. This release addresses feature suggestions with over 500 votes on our public issue tracker. Here are some highlights:

Code Search

We announced code search back in April and we’re proud it has graduated from our Early Access Program and is now generally available for Bitbucket Server and Bitbucket Data Center. Searching for code is a highly requested feature by our users, and for good reason – as the amount of code you have inevitably grows, it can be tough to find exactly what you’re looking for. In 4.6, you can now search for code directly from the search bar, and also:

Search for code across all your projects and repositories.

Search for code within a specific project or repositories.

Use search operators to get more precise search results.

Search for code based on the language it’s written in.

Commit message and timestamp in source view

When browsing a repository it can be useful to understand information about the latest change to a file to help guide you on your way. To help with this, the file browser now includes details of the last commit for each file, just like in Bitbucket Cloud. In addition, hovering over the commit will display the full commit message. This is a handy little interaction we’ve sprinkled into other pages too, such as the commit list and blame views.

Blame in diff view

Speaking of which, blame views are now available in more places. You might be familiar with the blame button in the source views. It’s based on the git command of the same and shows details of the last commit line-by-line. It’s great for chasing down bugs. Now, the blame view is available in diff views too, so a commit diff or pull request diff can tell you more about the nature of the changes you’re looking at and where they came from. For example, you can find out who last changed some code and then bring them into a pull request for an expert perspective by mentioning them in a comment. TL;DR: Stay. In. Flow.

But wait, there’s more!

Gone are the days of confusing timestamps; we’ve added the ability to set your individual time zone. Now remote users and distributed teams can set their own time zones, providing accurate local timestamps within the interface and notification emails. Admins can set the default time zone of the primary instance, but it won’t override a user’s preference.

Check out the release notes to read more about these new features and the other improvements we’ve made in Bitbucket Server and Data Center 4.6, or update now.