Beanstalk

As the clock winds down on 2016, there’s a growing emphasis for 2017 and the years to follow. And that emphasis is on the importance for knowledge workers to be able to focus in order to do their best work. The tool sets and work environments of the modern “office worker” are maximized for distraction, not for in-depth output. How can teams — big or small — ensure they’re set to be successful by consistently cranking out great work?

In his book Deep Work, Cal Newport makes the case that the people who learn to minimize distractions and increase their ability to focus for long stretches will be the most successful in the decades to come. He lists what he believes are the two core qualities required in order to thrive in the coming years:

The ability to quickly master hard things.

The ability to produce at an elite level, in terms of both quality and speed.

And the key to growing these abilities is to learn to work deeply. What is “Deep Work”? According to Newport, this type of work would be defined as:

> Professional activities performed in a state of distraction-free concentration that push your cognitive abilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.

And his end hypothesis is that this skill is becoming both more important and increasingly rare in our current economy, and those who master it will thrive. As a software engineer himself, Newport understands the importance. This quote from Rands nails it:

> If you’re a software engineer, your craft is code and you’re at maximum productivity when you have long uninterrupted minutes and each unexpected visual and auditory interruption is a unique opportunity to completely lose your train of thoughts, context, and hard to recover mental momentum.

How about your team? Do your designers, developers, and teammates in all roles feel that they’re able to do their very best, day in and day out? From our experience, that is not the case for many.

Early in 2016, I spent time doing in-depth interviews with 30 or so Beanstalk customers. When asked what the biggest pain point was, the following comment sums up a common sentiment:

> Keeping on top of things (Slack, bots, Beanstalk, Basecamp, Zendesk) is taking more and more time, especially since I wear so many hats on the team. Having multiple tools to manage projects and client communication leads to feeling burnt out. There is a desire to find tools that keep things all in one place.

From what we’ve heard, achieving focus is a difficulty more most teams. If you're building a product or servicing clients, how can you improve in this area?

At Wildbit, we think about this a lot and having taken many of the following steps.

Establish the culture

First, making any improvements in this area will be very hard if there’s no buy-in from your team at large. Having half of a team attempt to focus while the other half is responding to every email as they arrive, sending DM’s without thought, or stopping by the office or cubicle for any question is sure to lead to failure. While it is possible to make some small changes to your own habits, you’ll benefit far more — and experience less frustration — when this is a team effort.

And (hopefully) it starts at the top. Newport advocates for knowledge workers to sell their employers/managers on this entire concept. And here at Wildbit, we’re fortunate to have founders who understand the importance of doing our best (there’s a reason we have values like this highlighted on our site). When the suggestion was made early in 2016, our co-founder Natalie read Deep Work herself. And it had such an impact that focus was a key theme for our annual team retreat in 2016.

Focus is important enough that the new Wildbit office was designed with this in mind. Designers, developers, product managers, marketers, and writers … we all need quiet and solitude to focus on our tasks in order to product our best work.

It’s why our office was designed with a purpose.

And this is not something that is fixed once, then you’re set. In a recent town hall meeting, Natalie shared that it felt like as a team we were slipping back into old habits. This time around, she asked the entire team to read Deep Work so we’re all on the same page and reinforcing the practices.

In order to have some success with a culture of this sort, the entire team should follow the practices.

Choose the right tools

Once a team has established what is important to them, you can start to look for the tools that can support your priorities. And when it comes to working as a remote team, this requires tools that allow for communication without distraction. As the Internet matures, it’s becoming more clear that how we communicate affects our work and how we feel. As Jason Fried mentions in Is group chat making you sweat?:

> We’ve also seen strong evidence that the method and manner in which you choose to communicate has a major influence on how people feel at work. Frazzled, exhausted, and anxious? Or calm, cool, and collected? These aren’t just states of mind, they are conditions caused by the kinds of tools we use, and the kinds of behaviors those tools encourage.

As with many other teams, Wildbit uses a combination of Slack and Basecamp to achieve the goal of communication with minimal distraction. Both services include settings that enable us to keep up to speed on projects and activities related to our work (as well as build bonds with teammates), but without a constant disruption during the workday.

Slack allows you to set yourself to DND (do not disturb), while Basecamp includes several related settings (latest activity, reports, email summaries, notifications, and work can wait. And we’re all encouraged to turn off notifications, quit our communications tools, and even work away from our computers (example: we are all agreed to never use the @here qualifier in our product channels, instead mentioning specific people with their unique handles).

However, the tools are only as good as the resolve of the person sitting in the chair. You twist all the knobs and pull all the levers to minimize distractions, then sabotage your efforts by “checking in” manually. This is why the culture is the foundation for doing consistent, focused work.

Build habits and routines

Last, each individual contributor on a team can help themselves do their best work by creating routines that build habits. After, all the end results of our lives are built on the little things we do with regularity. Or, as John Maxwell puts it:

> You will never change your life until you change something you do daily. The secret of your success is found in your daily routine.

At Wildbit, this comes out in different ways for people in various roles.

Artem, one of our developers, has a strict routine for doing focused work, yet still make time to give advanced support to our customers. Each day, he does his project/feature work that requires depth and focus first. Then, he ends each day cleaning out his support queue.

This allows him to use his highest levels of energy on the things that will move our products forward and helping in customers in the long run. But he also gives fantastic support to our customers right now, consistently. And that consistency wins him a lot of brownie points with our customer success team: we know we can count on him following this routine, which helps us provide better support as well.

Another example is our customer success team. With 5 people supporting 3 products, we split our time between proactive success efforts and reactive support efforts. Providing top notch customer support has always been highly valued at Wildbit, but being in the inbox all day can make it hard to focus on a larger initiative.

To ensure that everyone makes the most of their success time, we take entire days to work on success related items. Even further, we try to schedule our focus days back to back so there is less attention residue from the support given in the previous day.

Putting little steps in place can have a big impact over time.

Cultivating an environment that both values focus and produce great work is not an easy task. But it’s a vital one. Most of us are figuring it out as we go, wading through the tools, processes, and sources of entertainment that fragment our attention. Making change in this area requires proactive efforts.

Our good friends at Tower have an exciting announcement. Their excellent Git client for macOS is now available for Windows! It’s written natively with stability and performance in mind. This brings all the great features from their macOS client to Windows.

Tower integrates with Beanstalk, allowing you to connect your Beanstalk account and create branches, new remote repositories, and more all from the app. Reverting a commit is as simple as right-clicking on a commit and selecting “Revert …” to roll back. If a merge has a conflict, it’s simple to resolve with Tower’s Conflict Wizard. And stashing and fetching is automatic with Tower.

If you’re a Git novice, Tower has you covered with extensive documentation, video tutorials, and an ebook. And if you’re a Git expert Tower includes great features you’ll love like support for git-flow and submodules.

If you work in web development, you know how difficult it is to change from one tool to another. It can disrupt your workflow, and adjusting can be an uncomfortable and painful experience.

On top of that, there’s a learning curve involved to get teammates up to speed with the new way of doing things. And if the adjustment is unbearable, you may find yourself wondering, “Was this change really worth the hassle?”

Change can be difficult, especially in the tech industry. But without being open to the idea, you could miss out on new innovations that'll make doing your job easier.

That’s what we’re about at Wildbit. Today we’re going to talk about how Git brings you one step closer to doing just that.

Most experienced developers know the importance of version control. But this article will highlight the benefits of Git, and how to help your team transition to it.

First, let’s discuss what makes Git different from other VCS like Subversion.

What makes Git different?

Git is a distributed VCS, while SVN is a centralized system based on CVS. Centralized means that there is a single repository on a remote server that all team members work on. The centralized server stores code updates and, as long as that server is online, the code is accessible.

Git uses a different approach from CVS and Subversion in that it uses the peer-to-peer model. Unlike SVN, Git allows you to base your repository on one or more remote repositories instead of a central location.

You can also publish your repository for other developers to access or clone if needed. This makes Git great if you’re on a distributed team, or work on open source projects.

If your SVN server goes down, there’s reason to panic. But with a Git repository, your colleagues can work with confidence, knowing they can still work on the repository locally. This saves you time, and worry when connection issues arise.

But that’s not the only advantage Git offers.

The benefits of Git

One way to help your team transition is to focus on the benefits of the change. It won't be easy, but focusing on the advantages of Git will give your team something to look forward to.

Here are a few of many benefits of Git that'll hopefully peak the interest of your team.

Branching made easy

Branching with Subversion can be a lot of work. First, you have to create a copy of your project tree in your repository using the svn copy command. This command creates a copy of your project in a new folder or directory. And you have to do this each time you want to create a new branch.

In Git, branches are pointers to a specific revision. There’s no need to create separate directories for each branch, Git takes care of that in a few keystrokes. Let’s think about what this all means for a moment.

Think about how long it takes to create or merge a branch with SVN. If you’ve asked yourself, “Why is SVN taking so long to run a simple command?” then this is one benefit that you’ll appreciate.

Git is fast, and most operations on Git take place on your local disk. This makes branching and merging happen almost instantly. No more waiting for commands to complete.

To add, branches are relative to the repo you’re working with. Remember, in SVN there is one central repository. But Git allows you to have several remote repositories, and host a repository locally.

Each remote repository can have its own set of branches, with it’s own unique purposes. This means if you want to experiment with your repository, you can create a branch in your local copy and test your code without exposing it to the rest of your team.

The staging area

Git gives you the ability to handpick the files you want to commit. SVN commits all changed files to your central repository when modified. Git does not work this way. Let’s say you made changes to two files, let’s call them File A and File B.

You’re ready to commit File A, but you want to check with a colleague before committing File B. How do you save the changes made to File B and still commit File A?

You can use the staging area as a holding place for files you’ve modified, but do not want to commit yet. For more information on how to use the staging area, check out our “Getting Started with Git” guide.

Ability to work offline

Another stark contrast is that Git allows you to get work done without an internet connection.

What happens if you’re wrapping up your work day, and you lose connection to the internet, or your corporate VPN is down? If you’re using SVN, you’ll be in a tough spot. But Git allows you to work uninterrupted by recording commits in your local repository. This means you don’t have to push changes to your remote repo until you’re ready to do so.

Workflow flexibility

Git will work with almost any workflow, and this includes a centralized workflow. While Git does not need a centralized server, you can sync with other Git repositories. This allows you to add multiple remote repositories to your project, and push and pull changes between them.

You can also use the “read” and “write” permissions to set restrictions on your project. This gives you ultimate flexibility when choosing your workflow.

Helping your team transition

Communicate

Don’t blindside your colleagues. Do yourself a favor and communicate your plans to transition as early as possible.

This allows them to examine what's needed before making the switched. If you have any who oppose the idea, why not share with them the advantages Git offers? This is also a good time to answer a few key questions such as:

“How and when do we want to move to Git?”

“How long do we want this process to take?”

Educate

Whether you have a team of Git experts, or newbies — you want to get everyone on the same page.

Educating your team goes beyond teaching them simple Git commands, but it also involves establishing a workflow. Or at least, starting a discussion about it.

Trying to figure out the best workflow after you’ve transitioned your repos to Git can be a recipe for disaster.

It’s also worthwhile to understand how to integrate git with other tools you use. Why not take a day or two to hack out these details with your team?

Educate your team on what it takes to get started with git, and how creating and comparing branches can help avoid coding mistakes before they happen.

Implement

The last step in this process is to put what you’ve learned into practice. You could start by converting one of your repos to Git. This gives your team the opportunity to get comfortable running Git commands, or using a new client.

Remember to be patient with yourself and your colleagues during this time. You will make mistakes when learning a new system, but the payoff will be worth it.

Making the transition to Git isn’t a walk in the park. And it isn’t for everyone. But these are a few of the many benefits it offers.

If you’ve thought about making the switch for a while, consider what’s preventing you from finalizing the move.

If you work on a distributed team, and want to improve your branching process, Git may be a change worth making. If you don’t have any VCS in place, Git could be a good place to start.

Over the last few months on the Beanstalk blog we’ve been covering best practices from commit messages to deployment processes, and to branch management. We thought this would be a good time to look at how to extend Beanstalk and improve your productivity.

There are three different ways to extend Beanstalk. The first is integrating your repository with other web apps. Our integration page highlights some of the possibilities. The other two ways come from webhooks and the Beanstalk API. Both of these allow anyone to extend Beanstalk.

Integration

Need to keep a colleague in the loop, but they don’t need Beanstalk access? Integration is the perfect solution.

Built by the Beanstalk team, an integration connects Beanstalk to other web apps. These fit around three different themes: Issue Tracking/Project Management, Time Tracking, and Team Discussion. They help you tie commits to issues and support cases or track time spent on the new flagship feature.

Integrations are on the repository level. To enable and explore integrations available, navigate to repository settings and click on “Integration”.

Some of the possibilities available:

Track time you spent on a commit and send that information to Harvest.

After triggering a deployment, Beanstalk will post to a Slack channel.

Tie your commit to a JIRA issue and assign the issue to another team member. The commit in Beanstalk will also link to the JIRA issue.

Here’s what a commit message posting time to Harvest would look like:

Adjusted header logo position [time:30m task:webdev]

This is what is looks like if you assigned a JIRA issue to a colleague via commit message:

Updated footer wording [#007 assign:John]

Webhooks

Sending data from Beanstalk to another web service is a snap with webhooks. Support is available for both modular and classic webhooks. Like an integration, webhooks can be set-up in the "Integration" section of repositories settings.

Webhooks send an HTTP Post to a URL that you specify and are triggered by events in the repository. After a webhook is triggered, Beanstalk will send a JSON payload to the URL with information about the event. Since this payload is in a JSON format, it can be parsed by the receiving server. This allows you to send data about the event and create services based on that data.

An example event would be each time a push is done to a Git repository. In that situation, some of the information Beanstalk would pass on is what branch the push was to, who made the push, and what files were changed.

To take things further with modular webhooks, you can run pre/post deployment webhooks. For example, you could configure post-deployment webhooks with Jenkins. After a successful deployment, Beanstalk would trigger a Jenkins job to run tests against the environment.

Here are all the events that can trigger a modular webhook:

On each push (Git).

On each commit (SVN).

Every time a deployment is finished.

Any comment is posted on a changeset, a file or a code review.

When a branch is created.

When a branch is deleted.

When a tag is created.

When a tag is deleted.

When a Code Review is requested for a branch.

When a Code Review is approved.

When a Code Review is canceled.

When a canceled or approved Code Review is reopened.

When a new Issue is added to a Code Review.

When a Code Review Issue is marked as resolved.

API

For all plans, Beanstalk offers an API. If you want to build tools or services integrating Beanstalk, the API is for you. With the API you can do nearly action as you would in the web interface.

Do you need to generate new deployment environments on the fly? Programmatically create a new repository? Assign permissions to the repository you just created? These are all done with ease if you know how to work with a well-documented API. Or, you can get creative and do things like share common Sass files between repositories.

There are some great third-party apps available. Magic Bean allows you to manage your deployments on iOS or Mac. Habichuelas and Beansprout are mobile Beanstalk clients for iOS and Android.

Zapier supports Beanstalk, allowing you to connect to thousands of web apps with Beanstalk. For example, when creating a new Beanstalk repository you could add a new card to a Trello list to assign tasks around the repository.

Extend Your Productivity

The tools and services you can extend Beanstalk with are limitless. From updating a status in your issue tracker or notifying your entire team of a recent deployment. We hope connecting Beanstalk with the other services your business depends on makes life a little easier.

Any developer can commit code — but knowing when to commit is often up for debate.

Most developers will admit that making a commit for every changed character, or keystroke is not best practice. After all, having too many commits can cause confusion, and clutter your commit history.

On the other hand, committing large chunks of code could lead to unfocused and incoherent commits. Somewhere in there is a happy medium, but how do you find that?

At Wildbit, we promote best practices by encouraging developers to commit early, and often. This article will focus on the benefits of doing just that. To begin, let’s focus on two attributes to keep in mind when making commits.

Commit Messages

We often talk about the importance of writing meaningful commit messages. These messages define the commit itself, and should be about one specific set of changes. And those set of changes should support that message.

In this light, addressing two separate bug fixes in a single commit, even if they are related would not be wise. Why? Good commit messages are often overlooked until you need to go back and find a specific change. But how do you locate that change if you habitually combine multiple changes into a single commit? It’s not impossible, but it’s not preferable, either.

With that said, here’s a question to ask yourself if you’re wondering what code to include in your commit.

“When I write my commit message, will it be about a single subject? Or will I be forcing other random and unrelated details from a separate issue?”

If you foresee yourself having difficulties constructing a clear, and defined message, it may be better to create two or three separate commits to flesh out your work.

What’s another way to test the quality of your commits?

Rolling Back

Let’s consider another scenario. Think in terms of rolling back to a previous commit. If you want to know if you’ve included too many changes in your commit, ask yourself:

“If I rollback to the previous revision, how much work would I lose?”

Let’s go back to our example earlier, but this time we'll view this with a different lens.

You’ve fixed two separate, but related issues. You add these changes to a single commit, but then you realized you introduced bad code when fixing one of the bugs. Now you need to rollback to a previous state. But how do you do that without removing the useful code you prefer to keep?

This is where things can become tricky, and in most cases you find yourself wishing you had segregated each bug fix into their own commits. When you have the habit of committing early, and often it's easier to see the journey of your feature.

Don’t take my word for it. Let’s test this out. Here are two git log code snippets of the same repository. Which snippet tells you more about the feature that’s being added?

Example 1

commit b0e77532b5a8cf236d95f1b3324aabc194568c60 Author: Ashley Date: Tue Feb 29 23:12:05 2011 -0600 added contact us box to homepage and about us page

Example 2

commit b0e77532b5a8cf236d95f1b3324aabc194568c60 Author: Ashley Date: Tue Feb 29 23:32:03 2011 -0600 added text fields on home page

commit b0e77532b5a8cf236d95f1b3324aabc194568c92 Author: Ashley Date: Wed Feb 30 00:52:09 2011 -0600 added text fields on about us page

commit b0e77532b5a8cf236d95ashdad44aabc194568c12 Author: Ashley Date: Wed Feb 30 01:15:32 2011 -0600 added buttons, and edit and delete options

The first code snippet describes the commit effectively. But that’s all it does. All the code has been consolidated into one single commit. If you’re looking for a specific piece of code, you’d have to sift through a lot of changes to find it. That’s not the ideal experience if you run into issues down the road.

The second code snippet shows the journey of this feature and how it has evolved over time. Now, you can revert to specific points of your development, without the fear of losing all of your changes. With this approach, it’s easier to show your colleagues all the changes that led to the end result.

Imagine walking up a flight of stairs that has missing steps. You may be able to get to the top, but if the gaps are too large, then it can be difficult.

Likewise, making small atomic, and self sustaining commits help you to think through the implementation process and write better code. If there are too many gaps in your commit history, it can generate a lot of confusion making it difficult to journey through your project.

Benefits

To summarize, what are the benefits of committing early, and often?

It’s easier to share your code. If you’re on a distributed team, its best to share your code as much as possible. Your teammates can integrate changes, and avoid merge conflicts worry free.

Context. When you commit early, and often you give your team and yourself a great deal of context. How so? It’s easier to track where a change was introduced because you have a detailed commit history. Introducing too many changes in a single commit, it makes it harder to locate problems when they come up.

Scope. Committing early and often will help you to see the journey of your project, making it easier to rollback to a specific revision if needed

Better commit messages. Better code. By committing often your messages will be focused, and meaningful because it relates to a specific set of changes, and not a series of unrelated modifications.

Summary

Remember, the purpose of the change is more important than the size of the change. Some developers feel that if you’ve only changed 1 or 2 lines of code, then you’re cheating yourself by committing a small amount of work. But that’s not entirely true. A small change like fixing a typo is worthy of having its own commit.

Don’t feel rushed to commit code because you’re wrapping up your work day. Remember, git stash is your friend that stores your changes until you’re ready to commit them. Save yourself time and improve the quality of your code by committing early, and often.

In order to have a reliable development process, you must take deployments into consideration. And while using services like Beanstalk or DeployBot are a step ahead of transferring files via FTP, you need more than just tools. If you put a solid, consistent process in place, your entire team and your customers will benefit.

The primary goal of a reliable development process could be summed up as, “No surprises!” And deployments play a critical part in achieving that goal. As Zach Holman puts it:

Your deploys should be as boring, straightforward, and stress-free as possible.

Let’s look at how a regular, consistent deployment process can help your team.

It takes more than bran flakes to promote regularity

The phrase regular process indicates regularity. That means it’s a task your team conducts on a regular basis. This results in familiarity and the lack of surprises alluded to above. If you're only deploying a huge change to your production environment once every 6 months, guess what? Your deployments will be stress-filled, not stress-free.

There’s a reason why continuous deployment is a goal for many teams. It achieves this regularity and gets your team to deploying more frequent changes of smaller impact. Beanstalk enables this type of process with automated deployments.

For your development, testing, or staging environments, Beanstalk can deploy your changes automatically on each commit or push.

Achieve clarity

As well, the phrase regular process indicates structure. Your team is familiar with this activity in a certain manner. Better yet, if you document your process, there is an artifact to refer to for new team members or those still getting used to how your team does things. This makes it far easier for everyone to be aware of a few important facts:

what was changed

where was it changed

who changed it

The team knows where to get this information because of the structure of your process. And Beanstalk provides plenty of options for how to find these details, ensuring the success of your process.

It’s easy to go back in time

Another advantage of a consistent deployment process is it enables you to think of your site or app in linear terms. You can picture your changes reaching back in time with each deployment highlighting a specific point your project/product’s timeline.

The beauty of this is the ability to go backwards. If things go south, if you introduce some bad code (and you will), rolling back to a point in your timeline is a simple step. Most of us have experienced that sinking feeling moments after overwriting the previous state of a production web server with no means of going back.

Having your code in version control gives you something to go back to in these scenarios. But that’s still a lot of work (rolling back your repo, finding the required files, or deploying from scratch once again). But when you use deployment services that focus on this stuff, rolling back is as simple as deploying the last clean version of your code. If you deploy frequently, rolling back involves a manageable, smaller group of affected files.

Again, Beanstalk enables this ability. Prepare a manual deployment and choose the desired commit to deploy again. Beanstalk will ensure your end destination is modified to resemble the state of your repo at the desired commit. Within seconds, you're site or app is back to the previously working state.

Time better spent

Last, this consistent deployment process allows your team to make the most of their time. There does not need to be any lengthy investigation with team members asking, “What happened?” Investigation of a specific deployment takes seconds with a deployment service. Those questions above (who, what, where) are answered in a matter of seconds.

Instead, teammates can focus on building that new feature with zero bugs. Or cutting page load times in half. Or deciding which new prototyping tool is best . Or whatev. When the toolset and the process are well known, it leads to a more relaxed environment where team members can focus on the things that matter most to them.

I recently had a conversation with a non-technical customer who ran his own business. He came to us with the statement, “I’m tired of my developers overwriting each other’s work!” We understand that pain — it’s why we build products that we hope make people’s jobs a little bit easier.

Cornerstone 3 Released

We’re excited to share that our friends at Zennaware have announced that the latest version of Cornerstone is now available. Cornerstone has long been our favourite client for Mac users who work with Subversion.

The latest version sports a completely redesigned interface, with major improvements to the source list and the inspector. As well, the new design fits more nicely with its environment, using Apple’s HIG (Human Interface Guidelines). It has also been updated to use macOS’s built in notifications. Performance and usability were also a focus and Cornerstone users should enjoy the changes!

Visit their site to review the full list of what’s new.

Being new to the Wildbit team, I was curious in learning how my new teammates use Beanstalk. At Wildbit, we use Beanstalk’s version control tools to ship every single one of our products. I also wanted to hear how my coworkers are using it for their own personal projects.

Myself, I have a run of the mill use-case for Beanstalk. I keep my personal website hosted in a Git repository and use our deployment tools to be able to update my site. It’s fantastic not having to use an FTP Client or copying/pasting files to my server.

Chris Bowler

In Chris’s introductory blog post Shane mentioned Chris’s love for Nacho Libre GIFs. In the best way possible he doesn’t disappoint in his usage of the GIFs, he has one for every situation. Chris uses Beanstalk’s Git tools to keep his Nacho GIFs in version control and tracked. He uses Beanstalk’s deployment tools to deploy the GIFs to Amazon S3. Using S3 lets him upload the files to a public location where he can have the GIFs use his custom URL for them. To take things to another level, he also uses TextExpander to create snippets to send reaction GIFs when appropriate.

He also uses Beanstalk’s Git tools help to maintain his personal website and blog. He uses Kirby, a flat file CMS to be to write posts locally. Using Kirby allows his blog to live in a Beanstalk repository. With a brilliant collection of Hazel, Transmit, and Automator he’s able to publish his blog. Hazel helps him automate his file tagging, remind himself if there’s a blog post he wants to write, and create the folder structure for his blog post. With Transmit and Automator he’s able to automate sending his files to his server to have them posted.

Natalie Nagele

Natalie loves our code preview tools to review our user guides which we keep in a Beanstalk repository. Wildbit has a fantastic writing process for editing and creating the necessary illustrations. The wildcard everyone in development can relate to is: how do all the pieces look when it’s live?

Since our guides are in version control, we can use Beanstalk’s preview feature. Our preview tools allow you to see what a web page looks like in the browser, including HTML, CSS, and Javascript, all within Beanstalk. It’s extremely convenient! Previewing the guides lets us see how the guide looks when it will be live on our site.

Eugene Fedorenko

Our talented front-end developer and designer uses Beanstalk to keep his dot files under version control. Since he sometimes works on different Macs, keeping his files in version control is ideal for him. He can make a change on one computer and push the changes to Beanstalk. When he’s on his other computer, he can pull down the most recent changes. If a config file has an undesired change, it's a Git rollback away from being in the previous state.

Ashley Harpp

Ashley has a great use of Beanstalk! Along with her husband, they run a free summer technology program in the Atlanta area. The program is called TechPath (Formerly, Camp Basic). They teach the basics of HTML, CSS, and design. TechPath has a goal of mentoring students on technology or introducing students to coding.

They use Beanstalk to teach the kids fundamentals of using version control in software development. When teaching, they've found two skills to help advance their students: sharing knowledge to build the learners confidence and always having patience. Patience is key as a student might have little tech knowledge and feel discouraged, and sharing knowledge helps them get over that hump.

Artem Chistyakov

One of our great developers, Artem, surprised and impressed me with how he’s using Beanstalk. Years ago, he developed a Beanstalk extension for Sublime Text 2. If Sublime Text 2 is your text editor of choice, you have to check this out!

From within Sublime Text you can run three different commands: View the file in your web browser with Beanstalk, preview the file using the before mentioned Beanstalk preview tools, and view the blame output for the file. Our blame output allows you to see which users modified a file, on which line they modified the file, and which revisions the modifications were done on.

What about yourself?

Wildbit is a truly remote company with more than half of the team working from around the world. This means we rely heavily on our communication tools. For day-to-day communication, we use Slack, which is a great and extensible communication platform. Today we’re excited to release a Slack bot that improves the experience of sharing code hosted on Beanstalk in Slack.

When working on Postmark’s new status page we had a lot of Slack conversations around the source code. There are a couple of ways to do that on Slack: you can either use Markdown or upload a whole file. Markdown is a great way to write a short code snippet from scratch, while uploading a file seems more appropriate for sharing something bigger. The latter even adds syntax highlighting that looks classy. What neither of them allows, though, is to specify a context and point to a specific line.

At the same time, at Wildbit we use Beanstalk to host and organize the source code for our projects. And Beanstalk has an awesome code browser that allows you to highlight a specific line, grab the URL and share it with co-workers.

It turns out, for sharing existing code, it’s easier to just grab a URL from Beanstalk and paste it into the channel. And, as you might already know, Slack parses and creates rich content for known URLs like Twitter, images (we love animated GIFs), etc. — a process called “unfurling”. When sharing Beanstalk URLs though, Slack doesn’t know much about it. And even if it did, it still would need a valid authorization token to access the file contents. So, pasting lots of Beanstalk URLs to the Slack channel looks far from being helpful:

In order to read the code, you have to click a link, login (if you’re not) to your Beanstalk account, take a look at the contents of the file and switch back to Slack to continue the conversation. And as you might know already, context switching is the productivity killer. It will also completely lack the context in the future, so you can’t just go back in history and re-read it. Add the fact that file contents could change in the meantime to make it even more frustrating. So after a few such conversations, I had a strong feeling about writing a Slack bot that would allow us to paste Beanstalk URLs to files and inject the contents of mentioned files directly into the conversion so you can get more context right in Slack.

Something like this:

During our last company retreat, Derek and I hacked together a side-project that implements this. And since Derek already had an experience with Botkit — a very nice JavaScript SDK for writing bots by howdy — we decided to stick with it. It turns out, the SDK allows you to create a bot from scratch quite easily and we’ve got most of the code written in a couple of days during the retreat (in times between sticking notes to the window and drinking beers while sitting in a pool. What wasn’t so easy, though, is to make the bot usable by other teams. Since getting file contents via the Beanstalk API requires authorization, we would need to require teams to provide us with a username and auth token to use the API. And since we didn’t want to host such sensitive information ourselves, we looked for some solution that would allow us to make this easy and secure. After a quick research we decided to give a new Bot hosting platform called Beep Boop a try.

Beep Boop is a hosting platform based on Docker and tailored specifically for running Slack and Facebook bots. It uses a GitHub repository to check out and start the bot’s server-side code on each push to the master branch. It also has a nice way of configuring your bot using a simple *.yml file.

The cool thing is an ability to add custom fields to require additional information. After you add these fields to the bot.yml Beep Boop will request this information when you add a bot to your team for the first time. Provided information will be then available at the runtime via Beeb Boop’s JavaScript SDK.

Beep Boop then will request (using a nice UI) and provide this information to at bot’s runtime. In development mode, it is also possible to add multiple teams to emulate production environment. Or even emulate the Beep Boop environment locally!

Limitations

We initially built a bot that listened to the conversation and waited until someone pasted the Beanstalk URL. It when fetched the contents of the file, got the context around the highlighted line and put it into the channel. What we’ve found out later is that it won’t work for private (direct) conversations (apparently, they are called private for the reason).

In order to work around this, we created an additional slash command. So now, all it takes to share a code snippet is to type /code and paste the URL. It is clearly not as convenient as just pasting the URL, but it solves the “privacy” problem.

Another general limitation of Slack is that we can’t do any syntax highlighting for these snippets. We hope the Slack platform will evolve and will allow language specific syntax highlighting in the future.

Open Source

Any software development team that values their code knows the importance of testing. It’s a process used for validating code quality, and functionality. Testing is often thought of in the context of unit, integration, and regression tests. But there is another form of testing that’s worth adding to this bunch. Testing changes before committing them could save you much time.

Some developers test pre-committed code by default, while others prefer to wait and see how the code performs on their server. Which process is more favorable? To be clear, testing before you commit isn’t reinventing the wheel of testing. In fact, here are 3 things to keep in mind if you frequently test pre-committed code.

Testing code before it’s committed should not substitute for QA testing.

It does not replace the standard code review process. Code reviews are important. It’s one of the primary features in Beanstalk and we’ve written about its benefits.

It is not a substitute for continuous Integration (running tests automatically after each push)

Testing before you commit is simply an added layer of protection. It helps you to find errors, and bugs more quickly, before they are pushed to your server. There are several benefits to this form of testing, but let’s start by discussing why some developers choose not to test before committing.

But I can just revert…

Let’s be honest, VCS’s like Git have made it easy to reverse changes. In fact, our team has written articles that discuss how to undo things in Git. The writers of the book, “Pro Git” have done so as well, with guides like “Undoing Things”. In a few keystrokes you can undo changes and be on your way to the next task. While this is viable option, is it the most efficient?

The git revert command can be be useful in some cases, and we’re not discouraging the use of it. But if you’re reverting to adjust trivial mistakes, or typos, then testing locally before you commit could work wonders for your process. There’s an anonymous quote out there, and I’d love to know who thought of it. It says:

“Why do we never have time to do it right, but always have time to do it over?”

It takes more time to revert and revise a commit, than it does to test a change before it’s committed. How so? If you have a local environment, you can save the changes in your code editor, and then test them without committing. But if you choose to commit first, and then test your code, there are a few steps involved in that process.

First, you’d have to make the changes to your code, and then commit them. Then, you’ll need to wait until the commit has deployed to a testing server. Finally, you’re in a position check and make sure everything is working properly. If you notice typos, broken image links, or if your code just doesn’t work — you’ll have to revert your commit, or make another commit to fix your code. This process could repeat multiple times and become time consuming.

But my code is perfect…

Even seasoned developers make mistakes. And if you’re still not convinced of the idea -- try to view testing as a way to validate your greatness. Having a process for testing doesn’t make you a bad developer — it makes you a thorough one. It's easier to focus on security holes, and larger issues that you might be overlooking when the real testing begins. But what else does testing do, other than save you time? There are several benefits, but we’ll focus on one today.

The benefits - Clean commit history

Your commit history should tell a story. And a great story is informative, detailed, and organized. When your commit history is clean and tidy — any developer can view it and have a general idea of what’s going on. Commits should be meaningful and intentional because they represent a milestones in your project. Are the majority of your commits like this?

“just realized the typo in last commit..fixed” “oh snap! I forgot this file” “Oh no! The sky is falling”

If your commit history is full of minor adjustments, and quick fixes, think about what you could do to limit these mistakes.Consider this illustration:

Joe is working on a feature branch and is short on time. He writes his code and then commits his changes without testing them. Everything looks okay from Joe’s perspective, but the code didn’t compile after a large merge. Later, Joe’s colleague, Chris commits his code on top of Joe’s changes, but it doesn’t work.

This is a typical scenario, so what’s the point? If Joe had tested before committing his changes he could have saved a lot of time. Now, both developers will need to review the code to understand what happened. And they’ll likely be adding more commits to explain what went wrong.

It’s not easy to follow this process, especially when you’re confident that your code is written well and free of mistakes. But committing untested, and possibly broken code into your repository is never ideal. Sometimes, it may be acceptable to commit something that’s unfinished. But this is not the preferred route. Best practice supports making complete, and logical commits. So now that we know one way testing helps, how do we begin the progress?

Setup a local test environment

Assuming that you already have a code editor like Atom, or Sublime Text in place, the next step is to setup your local web server. A server, in this instance, is software that you can install on your Mac or Windows computer that will allow you to run your project locally. If you’re working on a website or web application, there are a lot of options out there such as Apache, LightTPD, NGINX. There are a few others out there but Apache is a popular one because it comes pre-installed on every Mac.

After you’ve installed your web server, you’ll need to setup your database server like MySQL and PHP or any server side language of your choice. In most cases, this process is a one time setup. Once your testing server is ready, you can make changes to your code without committing them and view the results on your localhost or test server. If you’re looking for a detailed guide, the Mozilla Developer Network has a nice article on “how to setup a basic working environment”.

At Wildbit — testing isn’t an option

“A good developer tests their own code instead of relying on QA to find every bug.“ credit: Wildbit - Good / Bad Developer

For the Wildbit team, testing is a requirement. The understanding is mutual among the development team that code should be tested before it’s committed. It’s inevitable though, at some point someone will commit code that doesn’t build, or work as expected. This is normal, but if your goal is to save time, and minimize the frequency of changes we recommend testing as often as possible.

In comparison with most version control systems, creating branches with Git is effortless. Before the standard branch process, software teams used various methods to add features and fix bugs. Not long ago, a developer would make copies of the root directory in separate folders on their server to create new features. Once the feature was ready to go live, they'd hope that there wouldn't be any unexpected file conflicts when merging into root directory. This process was error prone, and led to much frustration. And trying to figure out who made what change, and which version to backup can be just as exhausting.

That’s where version control comes into play, and where a solid branching process makes life easier and more productive. Branches provide a lot of flexibility, and depending on your workflow, you can accumulate a lot of them in a short amount of time. This could lead to issues as it can harm performance in hosting services like Beanstalk, Bitbucket, and Github. To be fair, there is no golden rule on how many branches a repo should have. But there are indicators when a branch is no longer needed, or has little relevance. 

Deleting branches are hard

Deciding whether a branch is worth deleting can be a challenge. You may want to preserve a branch in case a bug returns once it goes into production. Maybe you have a colleague who wants to focus on that feature — without the hassle of sifting through all files in the master copy. We understand then, why there are no written rules about when to remove a branch. It depends on your workflow and team process. But if you’re overwhelmed with the number of branches in your repo, you may be in desperate need of a cleanup. Here are 3 key questions to consider when deciding if it’s time to delete a branch. 

When was the last commit?

If your most recent commit to a branch was a year ago, you should reevaluate its relevance. Creating branches in Git can be a breeze. And in a few keystrokes you can find yourself coding away new ideas and fixes to add on top of your master copy.

There is no harm in experimenting and testing ideas. But, if you have outdated branches in your repo that haven’t been accessed in years, you’ll want to consider if its worth keeping.

Let's face it, if you're knee deep in branches, you may have a tough time locating the outdated ones. Here’s a command that can help you view all your branches, starting with the most recent:

git for-each-ref --sort='-authordate:iso8601' --format=' %(authordate:iso8601)%09%(refname)' refs/heads

This command displays the date of the most recent commit for each of your local branches. Remote branches are not included, but this is great way to declutter local branches. If you’re a Beanstalk customer, you can access this data in the “branches” section of your repository. You can view the latest commits for each remote branch, without having to search for them via command line or GUI client.

Was the branch merged?

If having outdated branches is your least concern, then you’re off to good start. The next step in the cleaning process is to locate merged branches. In most cases, if you merged a feature branch into the master it’s safe to delete it. This can be a scary concept to grasp if you’re new to Git, but it’s not as daunting as it sounds.

It’s important to remember that branches are pointers to a commit. If you have merged a feature branch into the master, then both branches will now point to the same commit. Whether a branch was deleted previously or not, they can always be recreated. In fact, you can create a branch that points to any commit in your repo history.

This gives you a peace of mind knowing that your commit history will be preserved after completing a merge. Some teams have found success adding tags on the master branch that point to where a branch was released or merged. This helps you keep track of each branch release after merging it into the master. For tips on branch management, we recommend “Git Branching - Branch Management". You’ll find commands that you could run to view merged (and unmerged) branches.

Is the review process for this branch complete?

Many software teams use a code review process or an issue tracking product like Sifter to review code. If you use a tool like this, you’ll want to find out if there are any open or pending cases in your branch. If you stumble across resolved ticket issues, and approved code reviews, dig deeper. Consider what else is there left to do. Is it possible to merge the branch and then delete it? Is the feature discontinued? If the code review process is in limbo, take steps to ensure that it hasn't become the forgotten branch no one wants to work on anymore. If that has already happened, consider if it should removed.

To delete an abandoned branch, run: git branch -D old-abandoned-feature Removing local branches that are no longer on your server is another way to keep things tidy. The git remote prune origin command can be handy during these moments. This is the tip of the iceberg when it comes to pruning your repo and keeping tidy branches.

Summary

Keeping your branches minimal, and clean can help cut confusion for your team. It’s important to remember that version control was built to make the development process easier. In a sense, it’s a safety net that protects you from mistakes, allowing you to backup to any previous state. This means that most changes made to a branch are reversible. If you have merged a branch, you can undo the merge. If you delete a branch by accident, you can recover it by using the git reflog command.

In the current state of web development, it doesn’t take much work to put tools in your tool belt. Finding the options for any given job is quick work and the biggest challenge you’ll face is choosing which tool to use.

If tools are in abundance, what stops some teams from producing great results, time after time? What differentiates the prolific teams from the average ones? While there are usually a few factors, a big one is the lack of a solid, consistent development process.

Process Is Not a Dirty Word

If your eyes start to glaze over when someone says “process”, no need. Every team has a process, even if it’s not on paper and never talked about. Even the lack of formal structure is itself a process.

Taking a bit of time to discuss how you do your work is a smart investment. Although the best teams spend more time doing than talking about doing, never discussing your process(es) will cause you and your team headaches. Making a point of reviewing how you do your work once or twice a year provides a chance to step back and see the forest, not just the trees.

The point of this article is not to define what makes a great development process. We’ll tackle that another day (and you can get a sense for our opinions with our guides). Today the focus is on how to establish a process for your team.

If you struggle to complete your web or app projects, or want to ensure your successes are repeatable, this is for you!

Discuss

As alluded to above, your team needs to invest time to take a step back, evaluate things, and talk as a team. This can be hard in the rush of project deadlines, but you should make it a priority. Although discussing process does not have a direct financial return like launching a client’s website, it will contribute to the bottom line.

So find time in your annual schedule to meet and discuss. Identify where you could be doings better. Celebrate where you do things well. And most important, ask your teammates where they are feeling pain in their job.

At Wildbit, we meet as an entire team once or twice a year. Unlike some teams, this is not just a time to lay on the beach and sip cocktails (although that’s also important, especially for remote teams). We take these opportunities to think big, identify our goals, and come up with 6–12 month plans to meet those goals. And we take time to evaluate our tools, how we use them, and yes, discuss our processes.

Make the time! It should start from the first day someone starts with your team, then continue on with annual discussions at the least.

Document

Talking about process is only the first step. You also need to get it into a format that you can share. For your current team, but also for your future team. How great would it be for new designers/developers to receive a documented development workflow as part of your onboarding material?

The key with documenting (and processes in general) is to find the comfortable middle ground. Too few details will confuse your team members and leave them with questions. But too much detail means you’ll have to update things too frequently.

The team at Thoughtbot takes this to the extreme with their Playbook (which they’ve made publicly accessible). They’ve documented their entire process, from their approach to building products, to how they setup their laptops, to their hiring practices. You could argue this is overkill. But in a remote economy, new hires to this team know where to go when they have a question!

Find the right amount of fidelity so that your team has a grasp of the process, and the tools or services involved. Everything can then become routine.

Distribute

Last, get the results of the conversation and the documentation to your team. It’s important to have everyone review the discussion while things are still fresh. Your internal knowledge base or Intranet is a great place to store formal or official documentation like policies and procedures. That way, everyone knows where to go and find the archive of the discussion, plus the resulting documentation.

This is vital in 2016. As remote work becomes increasingly prevalent, documenting and sharing oral discussions is critical. There’s no point in talking about process if your developer in Serbia is unaware of the decisions. For remote teams, overcommunicating is the best course to follow.

Once a discussion is complete, someone on the team (preferably someone in a leadership position) should create a clean summary and post it online. Then ensure each and every person is aware of it. Using tools like Basecamp or Honey are great for storing documentation with some permanence, where as Slack or other chat tools are great for informing people about new documents.

The team at Zapier is 100% remote. Like many of us, they use Slack for sharing news, GIFs, and water cooler chat. But their documentation and processes are stored in P2, a WordPress theme. This gives both the original document and any resulting commentary a more permanent home.

Discipline

But you’re not done yet. Having a “set it and forget it” mentality is the surest way to ensure a process is never adopted. Once you have defined a process, documented it, and shared it with your team, you will have to reinforce it. Not in a punitive sense, but in the sense of reminding everyone of the discussion and decisions.

A great way to carry this out is at significant project/product events. At the first project kickoff or launch, point to the process. Pull out the documentation and review it once again. Ensure everyone involved is thinking back to the discussion and on board with the process.

How you do this differs from team to team. Dainius Runkevičius shares the processes of several teams and finishes with this:

As you may have noticed, different companies employ different practises to keep everyone updated and make processes as clear and transparent as possible. However, like everywhere else, there is no single rule for that. As a result, experiment yourself, try different approaches to manage processes within your company and find the one that fits your team best.

“Good programmers write code that humans can understand.” - Martin Fowler

Have you ever read a line of code and thought, “this is great, but I’m not sure I understand what’s making it work”. It may have even been your own code you were reading when having this epiphany. In either case, Martin Fowler’s statement is a powerful one, and few have tried to refute it. Code that is consistent, understandable, and well tested has high value in the development world.

But let’s face it, even experienced developers flirt with the idea of “cowboy coding” from time-to-time. It can be easy to see an issue in your code, and be tempted to implement a quick fix without going through the standard test and review process. There’s no judgment here. But there is a danger though, when cowboy coding becomes a habit.

Coding in the moment with little regard for future consequences or maintenance costs can be detrimental to you and your team. Quick-fixes are rarely practical solutions in the long-term. While there can be edge case scenarios to support cowboy coding, it is often stemmed by a lack of awareness for accepted best processes.

The root of cowboy coding

Demanding clients, and a lack of experience can make cowboy coding appear to be a valid way to work. Yet, while some clients may delight in the outcome, this could result in long term issues.

For example, coding fast to solve a bug issue while dismissing revision control, documentation, tests, and methodologies can be detrimental to the client in the future. Imagine you’ve built an application for a company and the end result was exactly what they expected. Some years later though, the company decides to hire another developer to work on the application. But the person hired for the job struggles because the code is unreadable, and buggy. This is not helpful to you and often is a huge disservice for the client.

Inexperience could also encourage cowboy coding. For example, an unseasoned developer may opt to use a local version control system. Instead of using GIT or SVN, perhaps they prefer to copy files into another directory. At face value, this could appear to be the most simple, and efficient route.

But often overlooked, is the high probability of error. For instance, copying files to the wrong directory, and overwriting files you want to keep. If you’ve found yourself or your team going down this path, you’re not alone. Here are a few practical tips that can combat the urge to cowboy code.

Focus on mentorship

Mentorships are opportunities to share knowledge, and to help those with less experience become better developers. This is true in any discipline, but the benefits are obvious in the development world. Statistics show that 35% of employees who do not receive regular mentorship will look for another job within 12 months.This is a broad statistic and isn’t specific to any field of work, but there is much to glean from it.

At some point in your professional career, you’ll need guidance. One way to remedy this would be to focus on mentorship. There are plenty of online programs available but options could also exist at your employer. Working alongside a senior developer could work wonders for inexperienced developers. Here are a few of the many online mentor programs available.

AirPair

Thinkful

Code Mentor

Another way to fight against cowboy coding is working on an open source project. This also gives a sense of accountability. Knowing that other developers will be building on top of your code will force you to think twice about the quality of it. Learning is an ongoing event, and accepting help from more experienced team members will enhance your productivity and your code.

Emphasize the benefits of best practices

Understanding the benefits of following best practices can be helpful to new developers. Instead of wondering why best practices are widely accepted — why not try to implement them and see how they can help boost productivity?

Embrace unit testing and other processes created to save time down the road. Investing in code reviews, quality assurance, and design inspection will go a long way for combatting cowboy coding. Using a version control system and valuing best practices is the foundation for writing structured, consistent and organized code. But while using a VCS has it’s advantages, it’s only the tip of the iceberg.

To get to the root of the problem, consider implementing a code review process. By enabling code reviews, code is connected to it’s author, thus assigning responsibility and a sense of ownership to the writer. This means that if you’re in a bind, or are in a rush to code you’ll be mindful of the way you code. Knowing that someone else will be reviewing what you’ve coded will remind you to create clear, and understandable code.

A solid code review process can help maintain a uniform coding style across the entire development team. This is one of the many reasons why your team should be doing code reviews.

A healthy amount of research could also extinguish any lingering doubts about why productive development teams use such methods. Here are a few guides and articles that we recommend checking out.

10 Best Practices for writing readable code

Git Tower Best Practices

Best Practices recommended by Beanstalk

Keep learning and be happy

While cowboy coding can be an enticing at times, being a catalyst for accepted best practices will go a long way for you professionally. Help your team flourish by valuing good policies, rather coding with little direction and without process. Think of ways for your team to share resources that can help everyone improve.

Security is a big deal here at Wildbit. For us, it’s not just mere lip service. We value your code as much as you do, and are committed to keeping it secure. But how can you be sure? There are so many tools available that can used for code hosting.

What’s available with Beanstalk?

In truth, it's difficult to highlight one thing that makes Beanstalk’s security top notch. It is our goal to ensure that our infrastructure is robust, and that your code remains protected. After all, we use Beanstalk to host our own code. 

While great security is of utmost importance to us, we realize that not all our customers desire to have every feature imposed upon them. Thus, we provide the freedom of choice. Each Beanstalk account owner has the power to control exactly how secure their account will be. 

Here are a few simple, key features you can put in place now to improve security, without making it a long and painful process for the rest of your team.

Two Step Verification 

“Treat your password like a toothbrush. Don’t let anybody else use it, and get a new one every six months”~ Clifford Stoll

Have you ever heard that expression? If so, then you know the various measures many have taken take keep their accounts safe and sound. With two factor authentication users select two or three factors to prove their identity. A password is still needed to log in, but you’ll also need your phone or another device to gain full access to your account.

By default, 2 step verification is disabled with Beanstalk. It is available to all Beanstalk customers, regardless of your  account plan or size.

Once enabled, Beanstalk will ask the account owner to set up, and verify their phone number. Each user on the account will need to complete this process to ensure that the account remains secure. Each user invited to your account after 2 step verification is enabled will need to enter their phone number after accepting the invitation.

The Benefits of Having a Backup Option

What happens if your phone is lost, or simply unavailable? We strongly recommend providing a backup number in these cases. This number will only be used in the event that the primary number is not available. You can use any secondary number you have as long it accepts messages, so a home phone number would not work in this instance.

Another great option would be using Google Authenticator. This is a free app for iPhone and Android that can generate verification codes in the event your device has no data or network connectivity.

Warning: If you’re using Beanstalk API and have 2-step verification enabled, all users will need to authenticate with an access token provided by Beanstalk. The API will not allow usage of passwords for all API requests, so this is very important. You can generate an access token by simply going to your Profile Settings (clicking on your name at the top right, then clicking “Access Tokens). You’ll want to ensure that all apps (like Git Tower) or web services that require your Beanstalk credentials to connect over the API are using the access tokens before you enable 2-step verification.

Restrict Access by IP Address

Another way to ramp up your security is to restrict access by IP address. This means that you can limit access to a particular IP address by sharing which addresses will be allowed to access Beanstalk.

The benefit? You can restrict a user’s access to a specific location or trusted network. This can limit the collective damage from an account if compromised. 

This feature will be disabled by default, but can be enabled by the account owner in the security settings. Our help article can help you get up to speed with restricting IP addresses.

This feature is only available to those on the Business plan, and can only enabled by the account owner. 

Automatic Login

For many customers, automatic login provides a ton of convenience. It can enhance the user experience beyond measure as there’s no need to recall a user name or password. You can simply go to the URL of your account from your default computer, and you’re ready to get started. But what if you view automatic login as more harmful than helpful? 

Automatic login will be enabled by default for each account. But it can easily be disabled in the security settings by the account owner. 

If you want the best of both worlds - and would like some type of password protection, you can always trigger a password protected screensaver to your work computer. That way, if you’re working in the office, and someone walks by, they will not be able to make changes to your Beanstalk account, without providing a password. 

Note: Disabling Automatic Login is only available to business accounts only. 

These features are only a tip of the iceberg when it comes to how we handle security. We pride ourselves on being as transparent as possible with our customers. In fact, our rigid employee policies ensure that only a select few are allowed access to the servers where customer information is stored. Keeping your data safe is not an option for us — it’s a requirement. 

Detailed commit messages are an essential part of any good development process.

Have you ever read someone else’s commit message, and wondered what on earth were they doing? Perhaps you’ve gone back and read some of your own commit messages wondering what you were doing?

At some point, most of us have fallen victim to writing commit messages that simply have no value. Perhaps you had a busy day, and didn’t have time to craft a meaningful message. Or maybe you simply felt that a commit you made didn’t warrant much detail because no one would need to circle back and read it again.

Whether it’s a matter of being lazy, or not having the time — commit messages are important. They are an communication tool that can elevate the productivity of your entire team. And when written effectively, your future self and your team will thank you for crafting such thoughtful and informative messages.

If you ask any developer to describe what an ideal commit message would look like, what would they say? Some reason, “If I commit several times a day, and I haven’t finished a feature — what am I writing about?” Others may say, “why do I need to write a commit when you can simply view the code”?

From the surface, these arguments may appear valid, but it dismisses the purpose of what commit messages are designed to do. Commit messages that are written with purpose and provide context help you get the most out of version control.

Meaningful messages do more than state the obvious, they indicate why a change happened. While anyone can simply inspect the revision history to see what has changed, it will not reveal what the developer intended to do.

Effective commit messages help you and your team understand why certain changes were introduced. Also, it simplifies the debugging process as you don't have to review hundreds of commits to discover where a problem resides.

Imagine reading a history book, that only contained dates of when certain events happened. There was not much detail.  The reader is then forced to assume much of the context of various historical accounts.

How useful would such a book be at helping the reader to discern the underlying cause and effect of problems?

Likewise, bad (or lazy) commit messages are essentially timelines that state the obvious — but leaves too much to the imagination.

What is a good commit message composed of?

Linus Torvalds (the “inventor” and main maintainer of Linux) put it this way:

A good commit message looks like this:

Header line: explaining the commit in one line Body of commit message is a few lines of text, explaining things in more detail, possibly giving some background about the issue being fixed, etc etc. The body of the commit message can be several paragraphs, and please do proper word-wrap and keep columns shorter than about 74 characters or so. That way "git log" will show things nicely even when it's indented. Reported-by: whoever-reported-it Signed-off-by: Your Name

That header line really should be meaningful, and really should be just one line.That header line is what is shown by tools like gitk and shortlog, and should summarize the change in one readable line of text, independently of the longer explanation.

Source

While there’s no strict definition of what a commit message is, there are a few guidelines and best practices to keep in mind. Good commit messages communicate the thoughts, ideas, and possible drawbacks of a change.

Here are 3 questions to keep in mind to up your awesome when writing commit messages.

Do your commit messages answer these questions?

Why was this change made?

Did you add a new feature? Fix a typo, or a bug? Did you improve performance in some area?        

For example: Instead of saying, “changed background” you could say, “Change background color based on 4/15/2015 A/B Test Results”.

What is the method behind the madness?

This simply answers why you decided to take a specific approach. Reference any online resources (like a Trello card, blog articles, etc) or relevant commits that will help provide context.

This may not be necessary to include for every single commit you make. But it should, at a very high level, explain how you decided to address the issue at hand.        

What are the possible drawbacks of this change?

This is a very important question. It should contain helpful information in the event you have issues related to this commit later. It may also expose that too many changes are taking place, and you need to simplify your commit. Learn more about atomic commits.

Taking time to thoughtfully create your commit messages, are well worth the investment. Informative messages provide a peak in the mind of the developer.

They are relevant, concise, and can save you and your team from much distress down the road.

We've added a few more helpful links below to help improve the quality of your commit messages.

Helpful Resources

A note about Git commit messages

Hidden documentation

One of the more exciting aspects of working as a team is adding new team members. But after going through the process of adding the new potential all star, reality kicks in: internal onboarding is a lot of work. You can do yourself, and your team, a lot of good with some preperation.

When it comes to hiring developers, this need is acute. Sometimes you hire an experienced dev who has worked on teams of various sizes. Othertimes, you hire a raw talent straight out of school. While the former are usually familiar with tools and frameworks, they still need to get up to speed on how your team works. And you hire the latter for potential, but they may have to learn new tools as well as getting acquainted with your workflow.

And, as many of you know, getting started with version control can be a daunting step for many. The following are a few helpful steps we’ve learned along the way. Both from our own team, as well as talking to customers of all shapes and sizes!

Document

This is where you and your existing team can help your future selves. As much as possible, document your current process. The tools you use, how you use them, and where the credentials are stored are all crucial for a new hire.

Imagine the difference for that person when they can spend the first couple of days reading documentation rather than worrying about asking too many questions. Imagine the difference to your current team members as well (also important).

Schedule a question period

As a follow up to the first step, schedule time for the new hire to spend with key members of the team. Questions will come up as they read about how the team works and the tools you use. Encourage them to document each one in the first couple of days, then give them a forum to get answers.

This will help the new person be comfortable in asking questions. And it will help your current team members remember what they forgot they knew. Gaining experience leads to increased knowledge. Foundational facts become so ingrained that we take them for granted. Teaching someone else forces a person to remember all the little steps along the way.

Have a playground

Once you’ve helped the new hire get set up with equipment, shared the team’s toolset, and discussed the workflow, let ‘em loose. Give them a playground environment to muck around. Trying things out without fear of negative consequences empowers people to experiment.

If this feels too expensive (in terms of money or time), ask yourself whether not having this in place costs more. The time required upfront to get some infrastructure in place for new hires will pay for itself. It can lead to confidence and familiarity when it comes time to work on something concrete!

Take the fear out of changes

For inexperienced developers, there is a crippling fear about breaking things. Help new hires remember this is exactly why version control exists! For many people, rolling back a document to a previous version with a tool like Dropbox is simple and intuitive. But for many, committing changes to your team’s repo is a much scarier step to take.

Remind them that commits are not permanent changes. Reinforce the idea that rollbacks and reverts are possible. Share your team’s processes for scenarios where this necessary. Remember your documentation we mentioned up top? Include why your team prefers to merge rather than rebase, or when to use a revert vs. a reset.

Documenting your team’s workflow, giving space to ask questions, and letting new hires play in a safe environment will help them when they begin to make changes in your projects.

Code Reviews are an opportunity to mentor

Last, make sure your team has a full, robust development workflow. This includes code reviews. Most developers understand the importance of such reviews for releasing quality code. But don’t underestimate the opportunity for mentorship.

Code reviews are a place for your experienced team members to check in on how new hires are maturing. They can create a safe place to give and receive feedback, allowing the less experienced developer to ask, “How would you approach this problem?” With the right approach, code reviews will bring the learning experience full circle!

Helpful Tools for onboarding a teammate

Here at Wildbit, we’re fresh off several new hires. Here are a couple of the tools that have helped us get our new friends up to speed:

Honey

1Password

Paper

Today we’re happy to introduce an enhanced and more useful dashboard. Our team uses Beanstalk every day and we felt like the current version needed some love and some key features. And you — our customers — told us the same thing.

After crunching data, analyzing feature requests, and multiple iterations, we’re excited to show you the biggest update to the Beanstalk dashboard to date.

The Beanstalk dashboard addresses two basic needs:

To provide a starting point for accessing repositories.

To give a high-level overview of what your team is working on.

Our old design wasn’t doing a great job for either. It gave a list of 15 recent commits across all repositories. This was not a good indicator of activity, even if your team is fairly small. And our research confirmed that most people ignored the dashboard and headed straight to the “Active repositories” list instead.

In the redesigned dashboard, we not only preserved that list, but made it a center element of the page and enhanced its functionality. It now it includes a number of commits and contributors during the last 14 days. Activity charts are relative to each other, so you can clearly see which repository has been the most active. (BTW, if a list of commits was an essential part of your workflow, it’s still available by clicking the “See all commits” link in the end of “Top 10 committers” section.)

One of the things that I personally find the most exciting is seeing recently deployed repositories and environments included on the dashboard. We discussed this concept years ago, but it never felt like a good idea for various reasons. With this redesign, we decided to include only environments in Manual mode on Dashboard. They are likely to be your most important production environments and won’t be updated after every push.

The “Your assigned reviews” section now shows names and descriptions of branches — that’s something we’ve been asked about a lot. It’s much easier to notice that you’ve been assigned a new review and get straight to it.

If you’ve ever wondered what your team is currently working on or who’s been the most active, you’ll like our new “Top 10 committers” leaderboard. It shows how many commits every person pushed this week, and also breaks them down by repository. You can even click on a bar and see a timeline of these commits filtered by user and repository!