Deployment previews for UI/UX teams · FeaturePeek

FeaturePeek has joined Netlify!

Wed, 19 May 2021 09:00:03 GMT

When we founded FeaturePeek in 2019, we wanted to create a way for developers get timely feedback from reviewers, a problem we often encountered when collaborating with product and design teams. And in the past two years, we’ve helped some amazing teams improve the way they review and iterate on web projects.

Today, we are thrilled to announce FeaturePeek’s acquisition by Netlify as our next step towards improving collaboration for cross-functional teams everywhere. In addition to offering a complete platform for building, deploying, and collaborating on web apps, Netlify is the original pioneer of deploy previews. Together, we’re launching the next generation of Netlify Deploy Previews, which includes many of the capabilities FeaturePeek users have come to love.

What this partnership means for FeaturePeek

The whole FeaturePeek team is joining Netlify, and we are so excited to be working with Netlify to create more collaborative workflows for developers on cross-functional teams. Netlify shares our vision that by building delightful, developer-focused experiences we can enable entire teams to work together better. We encourage all of you to try out the new Netlify Deploy Previews and let us know what you think!

We’re so grateful to be joining Netlify and working with talented, creative folks that share our vision around developer collaboration. We’re already planning new ways to improve Deploy Previews with the Netlify team, so stay tuned for more integrations and new tools to help web development team more efficiently share, review, and manage feedback on web apps.

What this means for FeaturePeek customers

To our customers, a heartfelt thank you! Our journey has only been possible with your support and your generous and constructive feedback. We’ve been lucky to work with some of the most talented and creative organizations, companies, agencies, and developers along our journey. You’ve helped us learn and grow, and ultimately build FeaturePeek into a developer-focused tool that enabled teams around the world.

With Netlify’s launch of collaborative Deploy Previews, we’ll be deprecating the FeaturePeek platform after 30 days from today, on June 18. We have tons of experience migrating developer workflows to a new platform, and would be more than happy to help your team migrate from FeaturePeek to Netlify to take advantage of the same collaborative tools you loved using on FeaturePeek (or to somewhere else, if you prefer).

Please reach out to us for help migrating to Netlify or if you have questions about billing or service availability.

Next steps

Go check out the new Netlify collaborative Deploy Previews!

— Eric & Jason

How FeaturePeek manages security

Tue, 29 Dec 2020 12:12:03 GMT

The development of web applications requires the cooperation of many roles; from design, to engineering, product management and operations. But security isn’t something that’s simply designed and done. Instead, effective security requires the coordinated buy-in of organizational leadership, designers, and the developers building and running the application. This is true about web applications that are being developed. But it’s also true about the third-party services that a web application depends on to function. If a third-party is vulnerable, it’s possible that a dependency on it could compromise your application.

This isn’t limited to production services, either. It makes sense that if an infrastructure provider (like AWS) is compromised, it would affect your production application. But what about during the development, staging, and product review phases? If you’re a web agency with enterprise clients, you might be working with sensitive proprietary information. Likewise, if you’re a developer at a major technology company, the website you’re building may be for a product that hasn’t even been announced yet.

So it’s no surprise that one of the most common questions we get asked by new users is “How do you manage security at FeaturePeek?” In order to help our users better understand our security objectives and practices, that’s why we put together this blog post.

1. FeaturePeek deployment previews are private by default

Did you know that some deploy preview experiences are indexable on Google? But that’s not the case with FeaturePeek. Our deployment previews are private by default, meaning that even if someone has a deploy preview URL, they can only access it if they’re logged in and on the team that owns the project. This way, you can ensure that only approved stakeholders have access to view your in-progress work and keep wandering eyes out.

2. We never store your source code on our side

FeaturePeek never stores your source code on our side. We request access to a repo’s source code to read the peek.yml configuration file, in order to see which repos are opted-in to FeaturePeek. This enables us to detect configuration details about each frontend, like the type of frontend architecture, and whether you to specified if your project is a static or Docker project.

3. We never write code directly to your repo

The only time we write references is via a pull request: when a user follows the project setup wizard and requests a GitHub Actions template to be added to their repo. Outside this particular exception, FeaturePeek will never write code directly to a repo. Configuring FeaturePeek doesn’t touch any of your production deployments, so you can tinker away without fear of screwing things up for your own customers.

4. We use HTTPS everywhere

To ensure proper encryption and security for FeaturePeek deployment previews, we exclusively rely on HTTPS-enabled URLs. Not only do we think this is a “no-brainer” best practice for your deploy previews, but we hope it helps give everyone that you send a FeaturePeek deployment preview link an added sense of confidence in content of what they’re about to review.

5. Your app is completely isolated from other users’ apps

Every FeaturePeek environment gets its own namespace in the cluster, so it’s completely isolated from other FeaturePeek users’ deployments. We chose to make this security design decision in order to make sure all our users’ deployment previews stay private and that their code is only accessed by authorized users.

6. FeaturePeek environment variables are encrypted at rest

Rest assured (excuse the pun) that we encrypt all environment variables. If your encrypted environment variables were ever hacked/stolen, their values couldn’t be recovered. We encrypt your environment variables to ensure your proprietary information and technological secret sauce is safely under lock and key. If you want to learn more about how Auth works at FeaturePeek, you can read more about it in our docs.

7. We use a password manager (and you should too!)

We’re big fans of password managers at FeaturePeek. Beyond the convenience of not needing to remember which password you use for each service, by choosing to use a password manager, you’re making it easy for yourself to make good decisions about your accounts and password choices. Whether you choose LastPass, 1Password, Google Password Manager, or another service, password managers are a simple way anyone can improve their own security on the Web.

Learn more

FeaturePeek turns your deployment previews into the hub for your team’s frontend product review. It’s the easiest way for UI/UX teams to collaborate on frontend code, and integrates with familiar tools so you can continue to use the services that you’ve come to know and love. From Continuous Integration services to container registries, and from bug tracking platforms to getting notified in Slack, we’ve got you covered.

FeaturePeek provides collaborative frontend staging environments on-demand, so you can collect implementation feedback from stakeholders sooner. Learn more about FeaturePeek Teams, our collaborative tool that supercharges deployment previews for development teams.

FeaturePeek CEO Eric Silverman on Beginning your career in Software Engineering (video)

Mon, 14 Dec 2020 12:12:03 GMT

FeaturePeek’s Eric Silverman recently joined Mintbean to share advice with new bootcamp graduates looking for their first job in software engineering. Eric discussed his path through build engineering at Apple, managing startup teams, and even his current stack at FeaturePeek. Whether you’re a new developer struggling with impostor syndrome, unsure of what job search terms will uncover that magical opportunity, or just curious to hear words of wisdom from a developer who has been through it, Eric’s presentation provides a load of insights to help equip those newly entering the professional world.

If you like this content, make sure to check out our friends at Mintbean. They’re a growing community of dev bootcamp graduates, self-learners, and other beginning developers that participate in weekly hackathons together. They offer free workshops that feature speakers from relevant startups and leading technology companies. Mintbean hackathons and workshops are intended to help new developers build their portfolios and ultimately find their first jobs in software development.

Below are some of the highlights of Eric’s workshop. If you’d like to view the whole 40-minute presentation, you can find it at the bottom of the page.

How did you get started in software engineering?

Decoding industry-specific job titles can be a barrier for new developers. “I had no idea what a build engineer was,” Eric explains, “I didn’t know what the field of build engineering was. I knew a little bit about compilers. And I knew a little bit about building software. But I didn’t know anything about the field I would spend the bulk of my career in.” That’s why Eric recommends new developers keep an open mind when searching for new jobs.

Whether you’re looking to touch all the parts of a stack at a startup, or want to build up expertise in a particular field at a large company, you can learn from Eric’s developer journey and the insights he’s gained along the way. In this video, Eric discusses how he got started in software engineering and answers questions about his first role as a software developer, what he learned while working at his first startup, and the benefits of working at a startup if you’re a new developer.

Why learn software fundamentals?

Even in a world where every question is a Google Search away, Eric suggests that it’s still important for new software developers to learn their fundamentals. “Tools change over the years; new methodologies, new platforms, new languages come up. But at the end of the day, a lot of the core fundamentals of software engineering are fundamentals for a reason and they’re applicable no matter where you are in your journey and in your career in software engineering.”

In order to better prepare for the professional world, Eric suggests new developers take their personal projects to the next level. Watch the video about to learn what Eric wishes he knew when he got started as a new software developer and some of his strategies for overcoming impostor syndrome.

What jobs should new developers apply for?

One of the best bits of advice Eric has for job-hunting software developers is that “the role you are probably perfect for might not be obvious for you.” That’s why it’s important not to take the easy way out when looking for job openings. Eric warns “it’s very easy to go to LinkedIn and type in software engineer. There’s so much you could be missing, especially roles that are really perfect for new engineers.” Look instead for positions like technical writer, sales engineer, QA engineer, DevOps engineer, and other more-specific roles to find more promising opportunities.

This video explains why many new developers aren’t aware of job roles that would be a great fit for them, things developers should know when starting their first software engineering job, and lesser-known roles that new developers should consider to improve prospects on the job hunt.

Why are interpersonal skills so important on software development teams?

“A lot of the times, especially with software engineering, it’s very easy to fall back on the fact that it’s logical. Your code compiles; it works or it doesn’t. It meets the spec, or you got all your bugs done, or you fixed this issue,” says Eric Silverman. “But so much of what you’ll find when you’re working on a team is interpersonal.” It’s important to bring your most positive self to build relationships with others on your team and create a reputation as a developer that others want to work with.

Find out how having a Growth Mindset can help transform your outlook as a new software developer and set you up for success on your new team.

How can new developers gain experience?

Personal projects are a great way to build out your developer portfolio and showcase your skills for potential employers. “Any time you’re really on your own figuring out something; that’s what real life is. That’s what developing software in a company is,” according to Eric Silverman. “So the more you can simulate that with a personal project, the better. You’ll get more reps. So much of software engineering is just doing it over and over, making mistakes, learning from those mistakes, making new mistakes, and then learning from those.”

In this highlight, Eric lists some of the best ways that new developers can gain experience while looking for a job, why it’s important to read other people’s code, and how contributing to open source projects can help you learn and look attractive to potential employers on your job hunt.

Beginning your career in Software Engineering (full video)

If you like these highlights and want to watch Eric Silverman’s full presentation on “Beginning your career in software engineering,” you can find the full video here:

Getting started in DevOps, CI pipelines, and setting up your first GitHub Actions (video)

Fri, 27 Nov 2020 12:12:03 GMT

Earlier this month, FeaturePeek cofounder Jason Barry joined Mintbean to talk DevOps and help new Mintbean developers set up their first continuous integration pipelines. If you’re not familiar with Mintbean, it’s a growing community of dev bootcamp graduates, self-learners, and other beginning developers that participate in weekly hackathons together. Past hacks have included trivia apps, stock trackers, chatbots, and lots more. Along with the hackathons, Mintbean offers free workshops and presentations that feature helpful speakers from relevant startups and industry leading companies. All Mintbean hackathons and workshops are all intended to help new developers build their portfolios and ultimately find their first jobs in software development.

One of the best parts of the Mintbean community is that every participant, code mentor, speaker, and community organizer at Mintbean are there to collaborate together and help each other learn. This focus on helping one another leads to a vibrant enthusiasm in Mintbean communities and chats, and new Mintbean participants always seem to think they’ve stumbled into a community that’s too good to be true. Except that it’s the real deal! That’s why the FeaturePeek team are so proud to be sponsors of the Mintbean community, as well as frequent presenters on DevOps and career soft skills topics.

Automate and Deploy with GitHub Actions

On that note, FeaturePeek cofounder and frontend developer Jason Barry joined a recent Mintbean cohort to discuss continuous integration and setting up your first CI pipelines. In this presentation, Jason chose to feature GitHub Actions for its ease-of-use and for its generous free tier. In this talk, Jason discusses the important of continuous integration, how to set up GitHub Actions, as well as some simple tests and automations you can integrate.

Don’t worry if you weren’t able to join us on 11/16. That’s why we recorded Jason’s session, and this way you can watch it on your own time. Before you start, make sure to check out Jason’s GitHub Actions Starter Pack repository on GitHub.

7 ways frontend developers can improve collaboration on UI/UX teams

Mon, 16 Nov 2020 12:12:03 GMT

When building anything, there is a necessary conflict between form and function.

Entirely functional products lack visual appeal and can be uninspiring to use. While products too obsessed with aesthetics can be confusing to handle, or expensive to make.

As a frontend developer, you’re on the frontlines of the battle between form and function. Because you’re the bridge between visual designers and functionally-focused developers, when deadlines start closing in and feedback flies fast, you’re the one on the hook. Whether that’s fair or not, frontend developers are responsible for ensuring effective team collaboration when it comes time for final review, bug fixes, and finally, delivery.

In this article, we’ll show you how to balance form and function; collaborate effectively as a frontend developer:

Why it’s important to think like a user
Speaking up early and frequently
Essential tools for effective team collaboration
Continuous learning makes you a better frontend developer
Feedback is essential and how small ‘picky’ design changes can add up to a big problem
How to make front end collaboration an organizational priority

We’ll also recommend some of our favorite tools and resources to make it easy, too.

1. Thinking like a user

The key to achieving a good balance between form and function is to get to know your users — and how they intend to use your product.

Good design and product development teams build intimate familiarity with the various personas of their users. By building empathy with your audience, you’ll be able to spot issues with usability in advance and make better decisions when prioritizing new features or bug fixes.

Some of the most successful startups start by developing their products to solve actual customer problems - where the customer need precedes the product itself. Regardless of the role your customers play in the creation of your product, it’s critically important to maintain direct feedback channels with your users.

By seeing the issues your customers experience with your product, you’ll identify where pain points occur in real life — not just in Figma or VSCode.

If you are building a website or other product without ready access to customers, try one of the websites below to gain impartial insights:

UserTesting: Used by Facebook, eBay and Walmart, UserTesting is the quickest way to get impartial feedback from customers. You pick your target market, assign them a series of tasks to complete and get a screen recording, spoken commentary and written feedback within hours.
UsabilityHub: Amazon, Google and AirTable use UsabilityHub. They allow you to create your own surveys (first click tests, preference tests, five second tests and design surveys) and invite your own participants, or make use of the UsabilityHub panel — comprising over 170,000 users.
Remote Testing: You can also use stakeholders or your existing contacts to get insights on your product. The U.S. Department of Health & Human Services has put together a guide on how to test remotely here.

2. Speak up early and frequently

You’re sitting in a planning meeting with the product manager, designers, management and other developers. You listen carefully, as the stories for the next sprint are discussed or longer term issues are debated.

Inside, you know there are usability problems with the product — and that while these issues would be simple to fix, they’re being ignored by the rest of the team. Whose responsibility is it to speak up?

This is a common pattern in many development teams, where opinions are bottled up and frustrated developers eventually move to a new job.

The good news is, it doesn’t have to be this way. By speaking up, you’ll improve the overall quality of the product, have a say in the direction of the product and work on improving your soft-skills.

As a frontend developer, you bridge both design and development. You are uniquely positioned to see when design or functional issues are harming product quality. And, as such, you should never be afraid to share your insights.

3. Leverage productivity tools to stay on track

Even if you’re the quiet type, preferring to focus on work rather than attend meetings, effective collaboration still requires communication.

You should make a continuous effort to be aware of what the rest of your team are doing - and that means staying on top of your team’s productivity tools. The benefits are:

Alignment: Teams that share a common vision build incredible products, as everyone is working towards the same goal.
Empathy: By staying in touch, you’ll understand your teammates skills sets and how you can help them be more effective.
Compromise: Make designers aware of technical limitations early. Cutting back an overly ambitious design around technical limitations can be soul destroying for a designer. By communicating early, you can avoid these issues before they occur, proactively compromising on form or function, as appropriate.

You should also frequently reach out to your designer during the development process. This certainly beats waiting until the end of the development cycle, to discover a design issue.

Some tools we recommend are:

Framer

Framer is a great design tool for building advanced prototypes that look and function like the final product. It works a lot like Sketch or Figma and should be familiar to both designers and developers.

You can see some examples of what is possible with Framer here.

Prototypes are a critical but often forgotten part of the development process. They allow designers to think of the product in a tangible way (rather than an abstract design) and let developers flag complexity early in the design process.

FeaturePeek

With traditional development environments, you need to deploy a branch to staging before you can get feedback, or hope the designer knows Git enough to set up a local environment. This wastes time and makes it difficult to roll out quick changes. In short, working with the design feels laborious rather than inspiring.

With on-demand staging from FeaturePeek, a preview URL is generated for every pull request with built-in feedback tools, allowing you to share and get valuable feedback quickly. When collaborators do give feedback, FeaturePeek automatically records the URL they are on, and their browser metadata, making it easier to resolve issues.

4. Always be learning

Frontend development is always evolving. New tools and frameworks are released almost weekly, each unlocking new possibilities to build better websites and products.

As a frontend developer, it is your responsibility to continually learn and adopt new technologies, as they might make a technically difficult design more feasible.

But how should a frontend developer approach continual learning? Here’s what we recommend.

Great newsletters keep you informed with no action needed. Just hit ‘subscribe’ and once a week you’ll get curated insights in your inbox. Some newsletters we recommend are:

Daring Fireball: A sarcastic weekly forum on technology (especially Mac-related), design, and culture
The CodePen Spark: A weekly newsletter, podcast, and community oriented around frontend development
JavaScript Weekly: A weekly email roundup of JavaScript news and articles
Frontend Weekly: A weekly roundup of front end related articles and news
Frontend Focus: A weekly email newsletter covering HTML, CSS, WebGL and other associated technologies
Pony Foo Weekly: A deeper dive into web technologies, sent every Thursday

Join online communities

Just lurking in online communities is fine for entertainment, but relevant online communities are a great way to stay at the cutting-edge of web technologies. Here you’ll find discussions about real issues other developers are facing — and how they solved them. Become an active contributor through comments or, even better, post original content about your own trials and experiences.

The top online communities for frontend development are:

Hacker News: Ignore the dated appearance, this online community is at the forefront of software development and entrepreneurship. People post links they find interesting, then (attempt to) have civilized discussions about the topic. You can also post your projects in the ‘Show’ section and get feedback from the community.
Dev.to: DEV is a “community of software developers getting together to help one another out”. DEV is a unique hybrid platform, feeling like a blogging platform, forum and chatroom all at the same time.
Indie Hackers: If you are building a product of your own, talk about it on Indie Hackers — a community for tech entrepreneurs.
Product Hunt Makers: You might have heard of Product Hunt as a place to discover new products, but they also offer a ‘virtual co-working space’ for ‘makers’. With over 25,000 members, this is one of the fastest growing communities in the space.

Learn by doing

Adopting an unknown technology on an urgent project is a recipe for disaster. New technologies are often poorly documented, so there’s not a lot of support if things go wrong.

Instead, create a sandbox project around the new technology and try it out. By building a tiny application or tool with no repercussions on your larger project, you’ll learn the new technology and discover it’s limitations first-hand.

Other examples of side projects you could build with a new framework are:

To-do list: A basic to-do list is a great way to learn a new language. There is an on-going project on GitHub which aims to build the same to-do app in every programming language — check it out here.
Weather: Try displaying the weather by using an innovative web technology. Could you use Lottie to animate weather icons, or WebAR to show the forecast?
Calculator: A calculator is a great way to learn state management frameworks, like Redux, Mobx or Flux.

Once you’re ready to test your new skills, or just want to build up a portfolio of side frontent projects, check out Mintbean. They host weekly hackathons with simple frontend challenges, as well as free workshops to help you upskill and improve job hunting strategies for new developers.

5. Get feedback often

Feedback is a key part of effective front end collaboration.

Developers should give feedback on designs as they are being created, flagging technical limitations as early as possible. Equally, designers should give continual feedback throughout the development process, too.

In the past, this was difficult for both parties. Designers could not see in-progress development work and developers couldn’t see design locked away in desktop applications.

But in 2020, cloud design tools like Figma, Sketch or Framer include commenting tools. Designers can see in-progress development work by using on-demand staging environments when using FeaturePeek.

6. Small design changes; big impact

Have you ever reacted badly to negative feedback, particularly ‘picky’ or small changes to the design?

Sure, you could choose to ignore these small tweaks, but they eventually build up — taking a big toll on product quality.

Remember, design is a highly skilled job that requires years of experience and specialist knowledge. If a non-programmer told you that a bug-ridden function was ‘good enough’ and ignored your feedback, you’d be frustrated too.

The next time you receive feedback from a designer, react positively and consider the change as an essential part of refining the overall product. You’re all on the same team, and small positive interactions over time are what make up great work cultures!

7. Change your organization

If collaboration between designers and developers within your organization is difficult, you might need to discuss a few internal changes.

Teams with effective front end collaboration:

Include developers throughout the process: By including developers from the start of the project, technical limitations can be considered and overcome at the start of the design process — rather than worked-around later.
Choose balanced project managers: Some project managers have tunnel-vision, focusing too much on one particular discipline, such as business, design or technical considerations. This works well for highly specialized teams, but is a blocker when front end collaboration is needed. A well-rounded project manager understands all disciplines involved in the project; facilitating collaboration and compromise.
Work closely: Where possible, designers and developers should have tight, frequent feedback loops. Remote teams can use video chats and screen sharing to help with this.
Avoid jargon: Just like developers, designers have their own jargon. A designer might ask for more kerning, tracking and leading and get blank stares from a developer. A developer might ask for the ‘letter-spacing’ of a H3 and get the same blank stare back. Instead of relying on technical language, encourage your organization to adopt tools for visual communication — a screenshot, Loom recording or Figma design is much clearer than a written or verbal explanation alone.

We hope these tips help you work more collaboratively with designers (and fellow developers!) to build high-quality products.

In 2020, it is not enough for a frontend developer to just write code. You are responsible for effective frontend collaboration. Truly exceptional frontend developers bridge the gap between design and development, helping the designers and developers on their team to build the best possible product.

Learn More

FeaturePeek deployment previews are the easiest way for UI/UX teams to collaborate on frontend code.

FeaturePeek provides collaborative frontend staging environments on-demand, so you can collect implementation feedback from stakeholders sooner. FeaturePeek works with all frameworks and hosting providers, so you can keep your tools and you’re never locked in.

Learn more about FeaturePeek Teams, our collaborative tool that supercharges deployment previews for development teams.

It's Not Design Culture Anymore, It's DevOps Culture. And We Should Adjust Accordingly.

Tue, 27 Oct 2020 12:12:03 GMT

Have you noticed that a lot of your friends who used to be Designers are now UX Architects?

Did their jobs really change? Or is their output being used and valued differently by the organizations that employ them? As a mainstream culture, we’ve really only become comfortable with design-thinking over the last 50-75 years. Today, designers are more important than ever to facilitating the product development process. But designers’ roles are undergoing a critical transformation.

In the modern workplace, design culture is everywhere and it’s had a lasting impact on the way organizations function. But while we’ve been paying attention to one very important way that work culture has changed, we have been potentially ignoring another, even more significant shift. Software development, and increased demand for software developers by both technology and more more traditional businesses, has shifted the culture of our workplaces and changed our expectations for how work gets done.

Like designers, software developers have never been more in demand. Today they can command high salaries and frequently can improve their prospects by 50% or more simply by moving jobs. Companies are now employing recruiters whose sole focus are attracting technical talent. And more developers are represented in business and technical leadership positions than ever before. These are relatively recent changes, but they’re already beginning to affect our workplace cultures. In this blog post, we’ll explore how increased the increasing gravity of developers is shifting the balance of our workplace into becoming DevOps cultures.

Using the mainstreaming of “design thinking” a template, we’ll look at some design collaboration tools that have been adopted by mainstream businesses. Then, we’ll look at some developer-centric collaboration and productivity tools and discuss how their adoption could impact the ways software development teams and entire businesses will work together in the future.

How DesignOps Tools Changed the Way We Work

Designers have a whole assortment of tools at their disposal. But most of the tools that designers use can be distilled into one of two categories. The first type are design tools, in that they are the bits of software like Figma, Sketch, and Adobe XD, where the primary purpose is to enable the act of designing and creating. The second type of design tool is one that helps designers communicate and collaborate with other stakeholders, sometimes referred to as “DesignOps.”

AirBnB explains their need for DesignOps tools, as their product teams are “working daily across so many disciplines, from Engineering to Product Management, Research, Content Strategy and an array of Design specialties, every little overhead in the transfer of information compounds. Inversely, every optimization and positive connection significantly lowers friction for everyone.” DesignOps tools ensure that cross-functional product design teams have visibility into each others progress, and removes friction by enabling each discipline to contribute, in context, whenever is convenient (within the project schedule).

Tools like Zeplin help designers make their design systems shareable and accessible to developers and other designers on their team. In other words, the Zeplin app helps with the people-side of design operations. This is why it’s helpful to view DesignOps tools as platforms for facilitating team collaboration. Because DesignOps tools make information accessible, teams can rely less on in-person or virtual conferencing more productively allocate their time resources.

The benefits of DesignOps tools are clear, so much so that traditional design tools are incorporating collaboration features as part of their longterm product roadmaps. In the same way that introducing collaborative features will enable traditional design tools to adapt to the requirements of DesignOps culture, businesses will increasingly turn to collaborative design experiences to enable their internal design processes and procedures.

How DevOps Tools are Changing the Way We Work

Like design tools, developer tools also come in many flavors. Traditionally, developer tools have focused on enabling the act of software development, as in coding. These take the forms of text editors like Sublime and IDEs like VS Code. But a developer’s everyday experience isn’t just limited to what gets deployed. Like designers, developers also rely on tools to help them collaborate, make their work accessible to others, and ultimately deploy to production. These tools are commonly described as having to do with DevOps.

DevOps is really just a way to describe the design, development, deployment, and continuous operation of software code, including all the tools and mechanisms that support those processes. Atlassian warns that DevOps is “not a matter of simply adopting agile planning or automated testing or continuous delivery.” Instead, they describe that “DevOps culture is all about a shared understanding between developers and operations, and sharing responsibility for the software they build.”

As developers become increasingly central to business operations, the tools that they use to collaborate with peers and non-developers on product teams will play an outsized role in facilitating everyday business operations. You can already see evidence of this now. For example, even if you’re a non-developer you feel the impact of a Slack or Zoom outage. And if you are a developer, you know exactly how (un)productive your day is when GitHub is down. Just like these examples, new tools are being created everyday to support DevOps and remove the daily frictions experienced by software developers. Ultimately, these are the tools that will deliver immense future value.

Here are the main types of DevOps tools that have already become, or will become, ubiquitous for modern software development teams:

⚙️ Platform-as-a-Service (PaaS) and Serverless There are lots of ways to build and host your web application. Platform-as-a-Service providers like Netlify and Heroku provide a more streamlined user experience compared with AWS, Microsoft Azure, or Google Cloud, while all four provide scalable infrastructure services to support applications of all sizes. Serverless architectures take the notion of abstracting-away infrastructure a step further, and adopt an overall philosophy of offloading all (or as much as possible) of the infrastructure responsibilities to third-party services.
🚧 Deployment Staging and Visual QA Every software development process that has a visual component or user interface will have some sort of visual review process. Web platforms like Netlify and Heroku have native deployment preview solutions to preview UI/UX work. FeaturePeek is a developer tool that makes deployment previews collaborative, so designers and other non-engineer team members can easily comment and leave annotations on the in-progress UI/UX.
🚢 Containerization and Deployment Containers, like those used in Docker, can make it easier to operate your application, especially when dealing with complex deployment environments. Services like Kubernetes can help you orchestrate and monitor your containers. Some of the benefits to adopting a container-based architecture include the ability to build once, run anywhere - a self contained process, and the freedom to package absolutely everything needed to run your application in a convenient way. Containers are modular, interoperable, portable, reproducible, and scalable. So it’s no surprise that while containers are not used everywhere, they’re quickly getting there.
🔄 Continuous Integration and Deployment (CI/CD) Integration is the act of checking that the code you just wrote didn’t break something you weren’t working on directly. Continuous integration, or CI, is doing this continuously to make sure issues are caught and addressed incrementally rather than all at once. Tools like Travis CI and CircleCI are good bets when considering continuous integration. Deployment is the process of launching your code onto the server, and there are lots of different ways to accomplish this. You’ll want to think about choosing an automation server like Jenkins and whether you’ll need a delivery platform like Spinnaker. Together, CI/CD is the collection of integration checks and test run to ensure code properly integrates, along with the steps needed to safely and reliably deploy your code onto your server environment.
🌡️ Performance and reliability monitoring In order to effectively operate a software application, you need to be able to troubleshoot when issues occur. But before you can identify a fix, first you need to know what happened. Logging is the continuous recording of application events, so that developers can assess and problem-solve issues as they occur. But logging itself is a passive activity. Monitoring answers questions about how the system is running, and involves continuously observing a set of KPIs about performance and resource usage. Datadog, AppDynamics, and New Relic are some of the leading providers of monitoring solutions.

Learn More

FeaturePeek brings DesignOps and DevOps together. The easiest way to set up on-demand frontend staging environments, FeaturePeek creates a deployment preview of your frontend every time you open a pull request. A drawer overlay makes it easy for your reviewers to leave comments, take screenshots with annotations, capture screen recordings, create tickets on popular bug-tracking platforms, and more.

FeaturePeek works with static sites and sites containerized with Docker. Best of all, you don’t have to migrate to a new cloud ecosystem. Whether your company’s website is hosted on AWS, Google Cloud, Heroku, Digital Ocean, whatever — since FeaturePeek is infrastructure-agnostic, you can use FeaturePeek no matter who your hosting provider is.

Try the 2-week free trial to see how FeaturePeek can improve your team’s development productivity.

The benefits of on-demand staging environments

Mon, 19 Oct 2020 12:12:03 GMT

TL;DR: Test features in isolation. Test releases as a whole.

You know the drill: it’s the night before a release, and your dev team is scrambling to address last-minute feedback before deploying to production. Most of the feedback surrounds tiny changes that are trivial to fix — but some of the feedback requires larger, substantial change. These long feedback loops reveal a more fundamental issue of communication breakdown. This should have been discussed earlier. Now you’re left wondering if it’s worth delaying the release to help ensure the stability of the build.

Sound familiar? I experienced this first-hand while working at a small (~6 engineers, ~2 designers, 1 PM) B2B SaaS startup. The product team would give feedback about the latest build on staging with only a day or two left in the sprint, causing a last-minute rush by the dev team to implement those changes. Corners were cut to meet deadlines, and hastily-written workarounds were rarely refactored, adding to the backlog of technical debt as the next sprint was already underway.

If you experience these symptoms during the development of your product, then chances are that your team doesn’t have the right tools at its disposal. It turned out that the product team left feedback late because they didn’t have a stable URL where they could verify UI/UX until changes were on our staging server.

We needed a way to get stakeholder feedback earlier in the development cycle — well before features landed on staging.

What is a staging environment?

A staging environment is a replica of your production environment. There shouldn’t be any significant differences between your staging environment and your live website, with one notable exception: the staging environment is private.

Think of staging as the ultimate quality assurance check, where you can make sure everything works in as close to launch conditions as possible. You’ll catch bugs, avoid costly downtime, and give your developers the confidence to take risks.

How do you deploy to a staging environment?

The traditional deployment process to a single staging environment usually has four steps:

The developer builds and tests in a local environment, running on their machine.
Once they are satisfied with their work, the developer pushes their changes to a branch on the git repo, where they open a pull request. Continuous Integration runs automated tests — like linting, type checking, and unit tests — to catch any issues. If issues are found, the developer goes back to step
Once Continuous Integration passes, the developer’s peers conduct a code review. This is necessary to gain consensus among your team that the proposed changes are greenlighted to be merged into the codebase. Not only should reviewers look at the code, but they should run the code to confirm that the code operates as intended. The developer goes back to step 1 to address any feedback left by reviewers.
Once the changes are deemed copacetic by automated tests and peer reviewers, the developer’s branch is ready to be merged into the main branch. If Continuous Delivery is enabled, then merging to the main branch kicks off an automated task to deploy the changes in the pull request to your company’s internal staging server.

Depending on how your DevOps team configures your git repo’s webhooks, merging to the main branch may trigger additional steps. If your org follows the practices of Continuous Deployment, merging to master could roll the latest changes out to production automatically (hopefully behind a feature flag). Every DevOps team is different — check with yours to see which practice your company follows.

Why multiple staging environments instead of only one?

Instead of being constrained by all upcoming changes landing on a single server, you could have temporary, ephemeral environments that exist solely for the purposes of hosting the build of a given pull request. This is what we mean when we say that you should test features in isolation. Giving every branch in your git repo a dedicated environment is very freeing for both your developers and reviewers.

What you might not is realize that this comes with more benefits than just testing features.

Code review won’t block gathering product feedback

With a single staging server, your code won’t be deployed until code review passes, and you won’t have a link to share with other people on your team. If you want to double-check with a UI/UX designer that the animation you made is up to snuff, too bad — you’re gated upon code review passing before you can Slack over a link.

If any stages above fail (red), you have to go back to square one. This can be costly if you’ve already performed code review, a time-consuming operation.

But UI/UX designers don’t care about the quality of the code — so why should code review be a bottleneck for gathering UX feedback? Ideally, you’d be able to get their opinion before asking your dev peers to give your code a once-over. That way, you’ll eliminate an extra speed bump when shipping your feature.

Ephemeral staging servers that spin up on demand allow for product feedback and code review to occur before (or at the same time) as code review. If there’s something that needs to be addressed, going back to square one isn’t very detrimental, since not much time has passed. You eliminate a speed bump by batching product feedback with code review, rather than having one be a dependency of the other.

Prevent an integration warzone

Sure, your new feature that you’ve worked hard on works now — but since a single staging environment is the landing pad for your entire engineering team’s upcoming changes, a developer on your team may inadvertently push code that breaks what you wrote. Even now that you have an internal link you can share with a non-technical stakeholder, there are no guarantees that the link will continue to work, since it is actively being integrated with!

While a single staging environment is useful for testing a release as a whole, features should be tested in isolation. This means that an environment’s purpose should be dedicated to testing the functionality of a single feature, rather than a collection of many features. Save testing the collection of features for your QA server, after you’ve already tested each feature individually.

Lower the barrier for running peers’ code

Developers face a large amount of context switching when they are asked to review someone else’s code. The process is unnecessarily interruptive, and looks something like this:

Stop what you’re doing
Stash any unstaged changes
Fetch from origin
Checkout their branch
Install dependencies (and potentially restart your development server)
➡️ Actually verify the new feature and provide feedback
Checkout your original branch
Pop your git stash
Reinstall dependencies (and potentially restart your development server)

With on-demand staging environments, on the other hand, the running branch is waiting for you to verify and provide feedback. Developers can jump into the deployment preview straight from the pull request without needing to checkout files, install dependencies, restart their development server, or change anything about their local environment.

Avoid redundant code reviews

The point of getting feedback is to make more implementation changes that address the issues raised in the feedback session. The problem is that this will require another code review! Even though the proposed changes the second time around are (hopefully) small, your reviewers will experience déjà vu because they are now going over the same lines of code for the same feature implementation.

With multiple staging environments at your disposal, you could spin up a preview environment for your designers to critique while your pull request is still open. You wouldn’t need to request a code review from your developer peers until your designer gives the thumbs up ahead of time.

More opportunities for testing

On-demand staging environments can be configured to be accessible behind a shared URL, which unlocks a wide range of testing and quality assurance opportunities.

Cross-browser testing: Ensure your product or website works perfectly on a wide range of browsers and devices.
Accessibility testing: Run accessibility tests to ensure your content is accessible to individuals with disabilities.
User testing: Create a pool of test users or use a crowd-testing platform to discover usability issues before you launch.

Avoid environment drift

Single staging environments are often configured once and left to decay, becoming a DevOps chore. This leads to drift between the staging and production environments, as similarities between the two decrease. This increases the risk of bugs appearing in either staging or production, which makes bugs difficult to reproduce.

Examples of these drifts include:

Environment and configuration files getting modified by unsuccessful staging deploys, leading to extraneous or incorrectly named settings.
Time-sensitive security vulnerability updates being applied to production in a rush, leaving staging several versions behind.

Whereas your production environment is under constant care and attention from the DevOps team, an infrequently used staging environment is lower on the priority list. This can lead to an unreliable staging environment, which blocks your development team from launching new features.

More stakeholder engagement

In the past, stakeholders didn’t get to use the finished product until it was live. Instead, they got a brief scripted demo at the end of the sprint.

By giving stakeholders access to your staging environment, they can help with the quality assurance process and ensure that the development work completed meets their expectations. This saves time and prevents mistakes from accidentally shipping.

Increased developer productivity

With on-demand staging environments, developers can create as many staging environments as they require without asking DevOps to configure a new environment. Developers love it because they have the capability to spawn new servers, and DevOps loves it because they don’t need to field manual tasks of spinning up a server only for it to be taken down shortly afterwards.

Save your company time and money

Single staging environments are typically available 24/7 on a dedicated server or virtual machine. This is a waste of resources that could otherwise be used for production.

Furthermore, if you have several development teams, the single staging environment can become a bottleneck. Teams must wait for a staging environment to become available, waiting for other teams’ quality assurance processes to complete. This could waste days of developer productivity and encourage teams to skip straight to production, losing all the benefits of an effective staging environment.

Each on-demand staging environment, on the other hand, is only online for the duration of the pull request. When the PR gets merged or closed, the environment gracefully shuts down, so you only pay for what you use.

Single vs. on-demand staging environments

Instead of the single staging environment decaying while it waits for someone to use it, an on-demand staging environment is created dynamically, triggered by a CI/CD pipeline.

This means developer teams can have access to staging whenever they need it, simply by opening a pull request. As you’d imagine, this boosts productivity and encourages developers to use staging environments, reducing the chances of costly production bugs. Once a developer is done with the staging environment, the staging environment is destroyed, along with any configuration, environment, or installation inconsistency.

	Single staging environment	On-demand staging environments
Developer self-serve	❌	✅
Low maintenance	❌	✅
Prevents redundant code reviews	❌	✅
Can test features in isolation	❌	✅
Can link to a build while pull request is still open	❌	✅
Number of environments	1	Unlimited
Cost	Pre-allocated	Allocated on demand and reclaimed automatically

Having said that, you should still have a staging server where you can do QA before rolling to production. This is where you should do a final spot-check to ensure that everything is working as expected before going live. The difference is that the purpose of this server is to test the release as a whole, rather than each feature on its own. How do the new features operate together? If there’s a bug found, which pull request and which lines of code introduced the bug? These questions are much easier to answer when features are tested while the pull request is still open.

Shorten cross-functional feedback loops with on-demand staging environments

As a front-end developer, being able to dynamically create a dedicated environment for an unlimited number of branches is a very powerful feeling. I can control my own network of machines without needing to ask for cycles from DevOps! The asynchronous nature of asking for feedback on a fleet of ephemeral environments is liberating — I know that each deployment will be waiting for my reviewer exactly how I left it. And while I review my peers’ code, I can visually review the build alongside it without having to check out their branch locally.

It’s not only helpful to the developers on my team, but also helpful to the non-technical stakeholders too — they get a lens into the engineering process, and can voice their opinions while the implementation details are still fresh in the developer’s mind.

If your organization is struggling with shipping features (on time) that meets everyone’s acceptance criteria, the solution may lie in tooling. Notice where and when the speed bumps occur — handoff, development, code review, etc — to help identify bottlenecks. Ask yourself whether your single staging server is a limiting factor during your team’s development processes.

Learn more

The easiest way to set up on-demand frontend staging environments is with FeaturePeek. FeaturePeek creates a deployment preview of your frontend every time you open a pull request. A drawer overlay is added on top that makes it easy for your reviewers to leave feedback by allowing them to leave comments, take screenshots with annotations, capture screen recordings, create tickets on popular bug-tracking platforms, and more.

FeaturePeek works with static sites and sites containerized with Docker. Best of all, you don’t have to migrate to a new cloud ecosystem. Whether your company’s website is hosted on AWS, Google Cloud, Heroku, Digital Ocean, whatever — since FeaturePeek is infrastructure-agnostic, you can use FeaturePeek no matter who your hosting provider is.

Try the 2-week free trial to see how FeaturePeek can improve your team’s development productivity.

Pull requests are the new design handoffs

Tue, 29 Sep 2020 12:12:03 GMT

The line between UI/UX designer and developer grows blurrier each year. Every day, more designers are leaning into software development and learning to code. This has led to a new class of “full-stack designers.” The Flatiron School describes a full-stack designer as one with the ability to “single-handedly tackle every layer of software development.” With the ability to produce and communicate with both technical and non-technical stakeholders, full-stack designers are exceptionally valuable for cross-functional teams.

Similarly, design-literacy has become table stakes for many developers. Most UI/UX developers work closely with designers, and a certain aesthetic sensibility is required to produce polished UI/UX work. So it’s no surprise that many UI/UX developers find themselves picking up tools and skills that are more typically associated with designers in the course of their regular work. Additionally, smaller teams lacking available design resources may turn to frontend developers, or even product managers, to take on additional design responsibilities in support of existing projects.

Job roles will continue to blend, and UI/UX developers will require new tools to better collaborate with increasingly cross-functional teams. There will always be a need for practical tools that make the act of coding easier, but it’s a new class of social, collaborative developer tools that promise to play an outsized role in the workplace of the future.

🛠️ The Collaboration Toolbox: What tools UI/UX teams use to collaborate

In the past five or so years, we’ve seen an explosion of collaboration tools to support professional teams. While the list of collaboration tools may be endless, when it comes to UI/UX teams, they all boil down into four basic categories:

Communication tools 📺

Not much is getting done if your team can’t communicate. Out of sheer necessity, most teams already have this category squared away, for better or worse. These are your big names like Zoom and Slack, but there are also some smaller startups like Loom, Tandem, and others making moves in the team communication space.

You can check out this blog post, if you’d like to learn more about our thoughts on some of the leading communication apps available to development teams today.
Project management tools 📊

Project management software helps to ensure that requirements are clearly communicated and contributors stay on top of their tasks. Project or product managers are responsible for aligning stakeholders, so that designers and developers can focus on executing the project objectives.

Whichever tools you choose, the point of adopting project management software is to facilitate the design and implementation conversations that happen as a product is being developed. There are a ton of great options to choose from like Clubhouse, Trello, Monday.com, Basecamp, Asana, and JIRA.

Before investing time in a new project management solution, consider choosing one that integrates with any important internal tools to minimize headaches down the road.
Design collaboration tools 🎨

Not until the last few years have a crop of upstarts begun to unseat the incumbent Adobe, for the hearts and minds of designers. Today, there is a triumph of options when it comes to collaborative design software and they all have their unique offerings.

Designer-centric tools like Figma, Sketch, InVision, Adobe XD, and Balsamiq all go various lengths to make wireframes and other handoffs tolerable for UI/UX developers. Handoff tools like Zeplin make it easy for developers to interpret wireframes, and must straddle both the design and development worlds.
Developer collaboration tools 💻

The universe of devtools is myriad, and comes with all sorts of solutions for problems that developers may face in the course of their work. But for collaborating with a team, there aren’t as many options as you’d think.

Version management platforms have achieved outsized importance in developer life. GitHub, and to somewhat lesser degrees, GitLab, Bitbucket, and others are the de facto public forums for software collaboration. Organizations large and small rely on these platforms to organize and document their software code.

Then comes the challenge of previewing, and more importantly collaborating on, still-in-development projects. Some web platforms like Netlify offer deployment previews, but there’s no way to collaborate or leave feedback in context, within the preview itself. That’s left to Slack, Zoom calls, or email.

Team-focused tools like FeaturePeek prioritize the collaboration aspect, and make it easy to review and leave feedback on deployment previews. Reviewers can record screens, annotate screenshots, and even review responsive layouts on multiple devices.

🤦‍♀️ The Collaboration Conundrum: What tools do my UI/UX team really need?

With so many tools, and so much cross-pollination occurring between developers and designers today, it’s difficult to determine which tools your UI/UX team really needs to communicate and collaborate together.

In a design process, it’s often the handoff points where team communication can breakdown. Consider:

What are your handoff points during the product design and development cycle?
What tools do you use to facilitate collaboration during these handoffs?
What are the potential communication gaps during your handoffs?

By identifying the handoff points between different roles on your team, you can begin targeting the tools necessary to keep your team on track. Remember, the initial exchange of wireframes isn’t your only handoff. Designs and prototype versions are constantly being handed off between team members for development, review, and QA. While some handoffs may already have established tools and processes (ex. handing-off wireframes), others may lack an established process or tool (ex. doing visual QA for pull requests).

↕️ Pull Requests: It’s not just the deployment preview that’s important

Design handoff tools are great, but why aren’t we talking about developer handoffs? Tools like Zeplin are great for ensuring developers have convenient access to information within wireframes. But how do non-engineers engage with pull requests, and collaborate as a team on constantly changing code previews?

There are many good solutions if your end goal is simply the deployment preview itself. For example, if you’re a Netlify user, they have a reasonable deploy preview tool. Similarly, there are available tools like Tugboat, and a few others. If all you want is a staging environment for your pull requests, then most solutions are essentially equal.

But the reality is that real people are collaborating on this deployment preview, and they need to do more than just look at it. That’s why the actual deployment preview itself isn’t the point. It’s the collaboration that matters.

🚀 Why the next killer enterprise app will be a developer collaboration tool

Like Slack, GitHub, Zoom, and Clubhouse, it’s the tools that change the way we communicate our thoughts and ideas with others that change the ways we work. Each of these applications helps us communicate and organize with our own teams. But none of these tools extends fully into the world of software development. As developers become a larger demographic in the workplace, collaboration tools that enable the way developers work, and make that workflow accessible to others will find eager adoption.

This is why tools like FeaturePeek are so unique and exciting. FeaturePeek is an example of this new wave of developer tools that bridge pull requests and GitHub into an experience that is accessible for all users, and ultimately into a more social context. Just like design handoff software does for designers, and project management software does for product managers, developers also need their own tool to present pull requests in an accessible hub for the rest of the UI/UX team.

There’s an elegant simplicity to focusing on pull requests as the final handoff of the UIUX process. By turning a basic developer action (creating a deployment preview for a pull request), and turning that step into a collaborative effort, every pull request becomes an opportunity for a just-in-time iteration or optimization. It’s a more efficient way of working for UI/UX, and serves to reinforce a notion that developers long ago intuited: Pull requests are the new design handoff.

Learn More

FeaturePeek deployment previews are the easiest way for UI/UX teams to collaborate on frontend code.

Learn more about FeaturePeek Teams, our collaborative tool that supercharges deployment previews for development teams.

Why your deployment previews need to be collaborative

Mon, 21 Sep 2020 12:12:03 GMT

“FeaturePeek offers a simple and convenient solution that supplements our code review process and makes visual QA much faster and easier.” - Kay Mok, Developer, Sanctuary Computer

🤦‍♀️ Most UI/UX teams are ignoring their biggest communication challenge

While some organizations scramble to incorporate design-thinking into their everyday business practices, web agencies and other technology-driven businesses have already adopted design processes and tools into their everyday operations.

But even the most design-savvy organizations tend to completely ignore their biggest remaining communication challenge, and developers are left holding the bag. That’s because for all the design and collaboration tools in existence, none facilitate the final stage of the design process, when development teams undergo a series of reviews and iterations of the still-in-development UI/UX, collaborating with designers and project managers to ensure successful project delivery.

Without tools to gather feedback on deployments in a timely fashion, frontend developers end up cramming last minute feedback, bugs, and scope changes from stakeholders at the end of the development cycle. Not only does this create stressful time crunches, but unachievable deadlines due to last-minute feedback can lead to corner-cutting on implementation details, code instability, and unreliable applications.

💬 Bridging the developer-to-designer collaboration gap

Project management software like Monday.com, Trello, Clubhouse, JIRA, and many others help project managers communicate requirements and track project status. Design tools like InVision, Zeplin, Figma, and Sketch make it easy for designers to give frontend developers the information they need to create digital experiences from wireframes.

But what are developers supposed to do when they need feedback on a pull request from other stakeholders in the design process? Send them to GitHub?

Web platforms like Netlify offer deployment staging, but existing testing and deployment preview solutions are not collaborative, and they’re locked into specific platforms. And good luck getting timely feedback from non-engineers. Existing solutions do nothing to bridge the disconnect between design and engineering teams.

👊 The easiest way for UI/UX teams to review and leave feedback on frontend code

FeaturePeek is a collaboration tool that shortens feedback loops between project managers, UI/UX designers, and frontend web developers. Christine Kim, a developer at Sanctuary Computer, describes “we’re a team of design-oriented developers, and FeaturePeek has been an incredible tool for collaborating with designers throughout the development process. Designers can easily click on a FeaturePeek link, follow the progress of a project, and catch quality issues early on.”

Another developer at Sanctuary Computer, Conor Davidson explains that the team at Sanctuary Computer “built something like FeaturePeek for our company. Easily previewing PRs has become an essential part of our workflow. [But] we switched over to FeaturePeak from our own software and are not looking back. Y’all built exactly what we wanted, plus more.”

FeaturePeek plugs in with familiar tools, like Github, Trello, Clubhouse, and Monday.com, so you can continue to use the services that you’ve come to know and love. FeaturePeek fits into your existing CI pipeline, and works with all frameworks and hosting providers.

📈 The ultimate collaboration tool for frontend developers

FeaturePeek Teams, our tool for enterprise and agency development teams, gives UI/UX developers all the features they need get feedback from stakeholders and keep projects on schedule.

On-demand deployment previews let you see your build on another machine before committing to the main branch
Floating UI overlay for deployment previews makes it easy for your reviewers to leave great feedback
Third-party integrations with all your favorite tools like GitHub, Monday.com, Trello, and Clubhouse
Stay logged in to the web app you’re testing while you jump from deployment preview to deployment preview
Get your reviewers’ browser metadata automatically when they comment on a screenshot or animation
Copy edit mode makes it easy to try out text copy edits on the fly

Easily measure distance between elements, take screenshots of bugs, record animations, and more

✅ Get Started with FeaturePeek Teams Today

It’s easy to get started with FeaturePeek Teams. Developers can try out FeaturePeek teams for free, and pricing for FeaturePeek Teams can be found here.

FeaturePeek teams is ideal for teams of all sizes, so no collaboration challenge is too big or too small. Learn more at featurepeek.com and follow us on social media @featurepeek.

The WFH edition. Our ultimate remote working stack for frontend devs

Wed, 09 Sep 2020 12:12:03 GMT

Let’s be honest, frontend developers kinda had this remote working thing figured out before our latest post apocalyptic reality. Now, it’s still been difficult for us all to adjust. But if there were any demographic that already had the know-how and the tools to stay productive while collaborating remotely, frontend teams had it covered.

The challenge, most of the time, is just sorting through the overlapping options and developer-targeted Google Search ads to get to the tools that actually make your workflow easier.

Don’t worry. At FeaturePeek, we’re devtool nuts. And we try out just about everything we discover. Along the way, we’ve earmarked our favorites and fully incorporated many into our regular internal workflows.

You could try out everything by yourself. Or you can learn from what our team figured out. But before we jump into our favorite little-known remote working tools, let’s start by covering the basics.

Remote Working Essentials

These are the fundamental tools every remote worker needs. Most development teams will already be using these in their day-to-day efforts, but if you skip over these fundamental tips and tricks, you’ll struggle to make the most of the other tools we mention in this article.

The Basics: Team Chat Tools

Email isn’t exactly dead, but it’s no longer the standard for asynchronous communications. Development teams have used text chat to collaborate since the internet was invented. So if you aren’t using a communication tool like Slack already, adopting one should be your first step towards productive remote working as a development team.

Are there other chat alternatives? Sure. But we haven’t found any we like better than Slack yet.

Here are the key features of Slack that make it work for developer teams:

Channel Messaging: You can create unlimited channels dedicated to tasks, projects, issues, or initiatives. For example, you could make a #webbugs channel to triage issues in your web app or a #marketingsite channel to discuss a website update. By working in a channel, you can be sure that all the right people see the right messages at the right time.
Searchable Knowledge: Slack is a single place where you can find conversations and files related to your work. Never again lose an email attachment in a crowded email inbox.
Integrations: Bring all the activity you care about into Slack so you never miss a thing. For example, a new Jira ticket could trigger a chat message or a new pull request to notify the right people to review it.

The Basics: Version Control

It doesn’t matter whether you’re working remotely or not. Version control is a critical part of modern software development, for both remote and co-located teams. Whether you use GitHub, GitLab, Bitbucket, you’ve likely already adopted one that makes sense for your team.

Regardless of the platform you choose, the benefits are the same:

Collaboration: Without version control in place, you are probably working in a shared directory and hoping your colleagues don’t modify the files you are working on. Eventually, someone will save over your changes and you’ll lose your work. With version control, you can work on any file without disrupting your colleagues. If there is a conflict, your version control system will let you merge these files later.
File History: Without version control, keeping a file history is almost impossible. With version control, changes to files are automatically tracked along with a commit message (a brief description of what has changed) and you can view the history of a file whenever you like. This makes it easy to see how files have evolved and what might have caused that annoying bug.

The Basics: Video Conferencing

I, for one, welcome our new Zoom overlords. Video conferencing is inescapable in the new shelter-in-place environment. And while we’ve all suffered from Zoom fatigue at points this year, sometimes you just need to discuss a bug or issue face-to-face.

At FeaturePeek, we actually find ourselves using a few different video conferencing solutions. But if you need one platform to rule them all, Zoom is easy to use and includes features that are essential for development meetings, including screen sharing, annotations, and support for whiteboarding sessions on select plans.

Other solutions are available, including Cisco Webex, Jitsi Meet, Google Chat, and Whereby. If you pay for the Standard, Plus, or Enterprise version of Slack, you get video call capabilities, too.

Little-Known Remote Working Tools

With the basics in place, you’ll be able to chat with your team and keep track of development work. Now, let’s level up your remote working productivity so you don’t skip a beat while skipping the office commute.

Miro: Online Whiteboard

If you’ve ever found yourself wishing that your development team could just meet for an in-person whiteboard session, Miro is the next best thing.

By being physically present and taking turns to write or move ideas around, it’s easy to plan, share complicated ideas, and leave key information on display, such as project timelines or key tasks to be completed.

Miro brings that whiteboard online and enables remote teams to collaborate in real-time in a free-flowing and creative way — just like a real-world whiteboard.

Miro also doesn’t just try and replicate the meatspace whiteboard experience. They explored what being a digital whiteboard can enable, and it actually has some key advantages over a real whiteboard:

Infinite Canvas: There are no limits to the size of the Miro whiteboard. Create a single whiteboard for every project in your company, all reviewable from one place.
Add Files: You can add files from Google Docs to the whiteboard, which will be automatically updated and synced.
Collaboration: All team members can make changes simultaneously from wherever they are in the world.

Loom: Video Messaging

At FeaturePeek, we use Loom for all kinds of our video needs. Instead of writing a long email or Slack message to explain that annoying bug, try using Loom to record a quick video instead.

We also use Loom to generate quick and dirty developer how-to videos to share later as an .MP4. Unlike normal screen recordings, Loom captures your screen, microphone, and face at the same time. This encourages users to explain their thoughts as they record; perfect for highlighting bugs or creating demos to be circulated within your team.

Loom recently launched for iOS, enabling app developers to record and share issues quickly.

FeaturePeek: Deployment Previews

The FeaturePeek UI overlay makes it easy to file tickets to third-party apps like GitHub Issues, Trello, and Clubhouse.

Sure, we’re biased in recommending FeaturePeek. But the benefits of on-demand staging environments are huge for remote development teams:

Quicker Design Feedback: Get feedback from designers by just sending them a link. No need to manually deploy or help the designer set up a local environment. When they do give feedback, FeaturePeek automatically records the URL they are on and their browser metadata, making it easier to resolve issues.
Review Others Work: Switching to a colleague’s branch to review their work takes time. With FeaturePeek, every branch is a dedicated environment, instantly available for your review.
Quality Assurance: “Well it works on my machine” is a thing of the past. Get an instant preview of how your branch will work on any server.

Want to see how this could work for your team? Our entire website is open source on GitHub, so you can take a peek at the preview environments that deploy on our open pull requests.

Headspace: Meditation

Being productive isn’t just about tooling and apps. Being productive is also a state of mind.

Sometimes a project requires you to hype up. But more often than not, these days you’re probably having trouble winding down.

Research shows that mindfulness can help improve mental health. And according to a 2020 study, meditation reduces stress and improves cognition.

Headspace is an app that aims to make meditation accessible to everyone. Taking a few moments to re-calibrate can help when development work becomes overwhelming or deadlines start to cause stress.

When To Chat: Timezone Sync

If your team is distributed around the world, it can be impossible to figure out a mutually convenient time to meet.

With When To Chat, you enter your timezone, the timezone of the person you are meeting with, and your availability. It’ll automatically suggest a range of times instantly.

If you use Slack, you can add it to your workplace here. Then, just type /whentochat, then @ your colleagues. For example: /whentochat @gary @tom “Dev Meeting”

Learn More

Let us know how your remote team stays productive by sharing with us on Twitter and LinkedIn.

FeaturePeek provides collaborative frontend staging environments on-demand, so you can collect implementation feedback sooner. FeaturePeek works with all frameworks and hosting providers, so you can keep your tools and you’re never locked in.

Learn more about FeaturePeek Teams, our collaborative tool that supercharges deployment previews for development teams.

The 8 part guide to better code review checklists

Wed, 02 Sep 2020 12:12:03 GMT

Of all the productivity tools available to UI/UX developers today, few are as ubiquitous and effective as the humble checklist.

In “The Checklist Manifesto”, Atul Gawande explains that simple checklists can transform the way we work. In his book, Gawande was trying to find a way that doctors, surgeons, and nurses could deliver better, more consistent outcomes when working in an operating room - a literal life-or-death situation.

“We have accumulated stupendous know-how,” Gawande writes in his book. “We have put it in the hands of some of the most highly trained, highly skilled, and hardworking people in our society. And, with it, they have indeed accomplished extraordinary things. Nonetheless, that know-how is often unmanageable.”

Although software development isn’t exactly a life-or-death endeavor, we can apply the same lessons by using the power of checklists to priorize effectively when collaborating.

What is a code review?

When a software developer on a team wants to contribute code they’ve worked on back into the main project, they need to do a ‘pull request’ or ‘merge request’. It’s the main way developers contribute to software projects, but sometimes getting pull requests approved can be agonizingly slow.

Before this code can be added to the project, other team members will do a code review. This means checking for bugs, issues and suggesting improvements.

Why make a code review checklist?

Generally speaking, code reviews are great. They radically improve code quality, increase developer productivity and prevent bugs from ever reaching customers.

But without a good process, code reviews can be, in a word…painful.

Code review checklists help ensure productive code reviews. A code review checklist prevents simple mistakes, verifies work has been done and helps improve developer performance.

1. Pull Request Etiquette ✅

Start with the basics. Is the pull request you are looking at actually ready for review? To determine this, here are some key principles that should apply to all code reviews:

Frequent — To make pull requests more manageable, submit them little and often. If a pull request covers multiple days with no good reason, it should be split into smaller chunks.
Bitesize — If a pull request is too large, it’s difficult to understand. It should be broken down as much as possible.
Well documented — Does the pull request have enough comments to make it easy to review?
Follows the Single Responsibility Principle — Code should only ever solve one problem. If a piece of code affects a lot of the rest of the code in the project, it’s difficult to review.

If these conditions are not met, return the code to the contributor to be improved or separated into different pull requests.

This might seem initially harsh or counter-productive, but over several weeks your team’s outputs and productivity will improve.

2. Styling 🎨

Set some basic styling rules for your team and ensure these are followed. Consistent code styling is essential to ensure future developers can understand code easily and work productively.

Some basic rules:

Are variable names sensible and consistently capitalized?
Are there sufficiently descriptive comments throughout the code as required?
Are formatting preferences followed? For example, tabs or spaces, curly brace on the same line or new line, 80 character width or 120 character width?

To save time, you could check these rules are followed with an automatic code linter. Prettier is a good example for JavaScript projects.

Again, if these standards are not met, stop checking the code and return it to the contributor for review.

3. Security 🔐

Set security standards for your project and check these are being followed religiously. The rules to be checked will vary depending on your project and organization, but some best practices are:

Run your project through vulnerability scanning solutions, like LGTM
Don’t hardcode credentials for testing or include secrets in the repository
Don’t disclose too much information in error messages, which might give hints to an attacker
Ensure any database queries are parameterized
Don’t trust user or client input blindly — your client or web application can be modified. For example, URL parameters that access resources should be checked.

If you identify security issues in a code review process, stop and speak to the contributor. It might be a sign of a more serious issue in the project or a lack of training, both of which will need follow on interventions.

4. Performance 🏎

Is the project as performant as it could be, or are these obvious optimizations that might improve performance?

For example:

Can any of the code be substituted with a more performant library or a language native function?
Is there any debug or logging code that could be removed?
Is caching being used if applicable?
Are images and assets appropriately compressed?

There are a myriad of tools that can help you optimize the web performance of your project. Good places to start are Chrome Lighthouse (also called PageSpeed Insights) and DebugBear for frontend projects.

5. Testing 🧪

Tests automatically check that code does what it should, making them a key part of the code review process.

Firstly, check that tests are present and well documented for all common functionality. If some functionality isn’t covered by testing, it should be well documented why this is the case.
Secondly, make sure that tests are well isolated, so you can find the problem quickly if a test fails.
Finally, do the tests test the code? Often, they claim they do, but don’t actually assess the intended functionality of the application.

Jest is a good option if you’re looking into automated unit testing. For automated end-to-end tests, check out Cypress and Reflect.

However, always remember that not all tests are bullet-proof and shouldn’t be relied on completely, as the next checklist item proves…

6. Does it actually work? 💩

It seems simple enough, but we’ve all made this assumption before.

If you are on an agile sprint team, the code should always be checked against the acceptance criteria provided by your Product Manager or Product Owner. If acceptance criteria are not met, ask the contributing developer why.

Another common issue is that code works locally but not in production. All code being reviewed should be deployed to a staging environment that is consistent with your production environment. This prevents environment specific issues.

FeaturePeek users don’t have to worry about inconsistencies between staging and production environments. That’s because FeaturePeek automatically deploys your branches into a dedicated environment every time a pull request is opened. This allows the reviewer to see the changes instantly and share this with designers, managers and other non-technical stakeholders for further feedback.

7. Positive code review culture 😻

Before you send your code review feedback or sit down for a meeting, check that your comments will help your team to improve rather than be seen as criticism.

Code reviews are one of the most regularly occurring interactions you have with the rest of your team. Take the time to ensure you’ve framed code review feedback in a positive way, so that you’re contributing to a positive, collaborative code review culture over time.

It can help to reframe critical feedback as constructive statements. For example, if the code is missing test coverage, suggest “could more test coverage benefit us here?” to test and challenge the understanding of your team members.

8. Review the checklist constantly 🤔

Your checklist is only good if it’s up to date. That’s why it’s important to continually review your checklist and ensure it meets your needs.

Your code review needs will change over time as new team members join or your project gains new requirements. For example, if you added new tooling to your CI process, this should be included.

FeaturePeek gives reviewers a floating UI overlay for your deployments, making it easy for your them to leave great feedback. This way, you get feedback from reviewers sooner and keep your code review checklist up to date with the latest requirements.

Learn More

Checklists are just one of the many tools UI/UX developers use to keep productive. Let us know how your team stays productive by sharing with us on Twitter and LinkedIn.

Learn more about FeaturePeek Teams, our collaborative tool that supercharges deployment previews for development teams.

7 tips for webdev agencies to build better client relationships

Tue, 25 Aug 2020 12:12:03 GMT

New business rarely walks through the door unannounced.

Instead, new business is won in the weeks spent preparing, pitching, and planning for a project, long before you write a single line of code.

But that doesn’t mean you’re off the hook once a client signs. While planning and design phases are important to ensuring project success, it’s the handoff experience of staging, deployment, and pull request or PR reviews that ultimately determine the client’s experience with your agency.

This has led some agencies to assemble bespoke deployment preview solutions in-house. For example, developer Conor Davidson (@conordavidson) explains that the team at Sanctuary Computer “built something like FeaturePeek for our company. Easily previewing PRs has become an essential part of our workflow. [But] we switched over to FeaturePeak from our own software and are not looking back. Y’all built exactly what we wanted, plus more.”

Whether you’re determined to build in-house, or you’re interested in a complete solution like FeaturePeek Teams, it’s critical to establish a frontend staging and deployment workflow that simplifies collaboration with your clients and builds the trust and confidence that leads to repeat business.

Here are 7 more tips to help keep your webdev agency clients happy:

Establish clear expectations early

Let’s say you’ve been introduced, referred, or otherwise connected to a new client. They explain their problem and it looks like your agency can help.

Before you jump into the project, start by laying the foundations for an effective client-agency relationship by aligning expectations from day one. This is also incredibly useful when working with existing or past clients, who may be trying a new style of project with you or working to a different time frame.

Think about onboarding new clients by creating an ‘instruction manual’ for working with your agency. In other words, a how-to guide for collaborating effectively with your team. It should detail how you like to work, your expectations from clients, preferred handoff tools, your strengths, and even your weaknesses.

Here are some helpful questions to answer in your instruction manual:

Who will be responsible for communicating with the client?
How will communication be managed and recorded? Do you prefer email, telephone, or dedicated project management software?
How do you share progress with your client?
How do you expect feedback to be sent?
How does your billing process work? If you charge hourly, how is work evidenced?
How is development managed and planned? Are you waterfall, agile, or something else? How does this benefit the client?
Any other frequently asked questions about your working practices.

Know your audience

Webdev agencies do complicated work and so sometimes development teams need to use technical terms to describe what is going on. But not all clients are created equal when it comes to technical competency.

It’s important to know whether you’re covering something technical with a grizzled app veteran or an untested software project neophyte. Especially for less technically-savvy clients, you should avoid unnecessary jargon wherever you can — remember your audience.

If you must use a technical term or concept, define it immediately afterward or give a helpful analogy by relating it to something your client already knows.

Switching to plain English, from industry-specific buzzwords and tech speak, will improve your client relationships because your contact:

Will understand what is going on and be able to give constructive feedback
Will be fully informed and therefore trust you
Will have confidence in your abilities
… and will have the language to promote those abilities within their professional circle.

Be proactive and transparent

In a bad client-agency relationship, your client is constantly chasing you for updates on progress and waiting days for a reply. In a great client-agency relationship, the agency is proactive. This means frequently reaching out to your clients and keeping them updated on progress or issues.

On-demand staging environments like FeaturePeek simplify the collaboration process between webdev agencies and their clients. With FeaturePeek, a floating UI overlays your deployment previews, making it easy for your reviewers to leave great feedback. Christine Kim (@chrismekim), another developer at Sanctuary Computer, describes “we’re a team of design-oriented developers, and FeaturePeek has been an incredible tool for collaborating with designers throughout the development process. Designers can easily click on a FeaturePeek link, follow the progress of a project, and catch quality issues early on.”

Trust your process

Your internal dev team has already established a process and culture to help your agency execute efficiently. Agencies are fast-paced, and must work on multiple projects and support several clients in parallel. So it’s no surprise that many have developed core competency in building effective internal work processes, in addition to their design and development capabilities.

That’s why it’s so important to spend time educating your client on how your team works. Every client has different needs, but being transparent about your internal work processes can help your clients engage more effectively with your team. You’re the experts!

Whatever your process, it’s important to reinforce agency-to-client collaboration by trusting your internal collaborative process. By continuously iterating and communicating with your clients, as you do with your own teams, you help ensure the best possible project outcome.

Get client feedback early

Web development projects are often long and complicated, but with careful planning, you can deliver consistent value throughout the process.

Rather than waiting until the end of the project for a big reveal, break the project down into stages — delivering value in each. This way, not only does the client feel supported step-by-step, they’ve also got ample opportunity to feed back in an iterative way.

One way to ensure client feedback throughout the project lifecycle is to provide on-demand staging environments that make it easy for clients to share feedback early and often.

Feedback delivered late is difficult (and frustrating!) to respond to. While timely feedback keeps everyone aligned, satisfied, and motivated to get the job done.

Get business and development aligned

For many agencies, the individual or team that won the project, and the individual or team who manages the client, is often entirely separate from the development team. And this can be a recipe for disaster when it comes to happy client relationships.

Especially as everybody is managing remote and distributed teams in the middle of a global pandemic, more than ever teams are relying on collaboration tools to keep business and development efforts aligned. Having a single tool for visual QA that is accessible to both dev teams and non-technical users can help to keep everyone on the same page.

For Sanctuary Computer developer Kay Mok (@mokaymokay), this keeps their code reviews focused. She shares that “FeaturePeek offers a simple and convenient solution that supplements our code review process and makes visual QA much faster and easier.”

Keep it simple

There’s a reason why product teams are so focused on the Minimum Viable Product, or MVP. That’s because establishing a standard of minimum viability is key to ensuring your team is always working on the most important items at hand.

In Agile, for example, simplicity means building the neatest solution that might meet the requirements of your client, then incrementally building upon it until your client is satisfied.

This has several benefits for client-agency relationships:

Encourages regular feedback on work, improving communications
Reduces time spent on potentially over-complicated solutions, reducing client spend
Writing less code means fewer bugs, leading to less negative feedback

Learn More

Your clients are passionate about the user experience of their projects. FeaturePeek helps show your customers that you’re similarly passionate about the user experience you’re delivering to your agency clients.

Choosing the right tools helps ensure consistent, effective collaboration with your clients and helps build relationships that lead to repeat business. By reflecting on the quality of your client-company dynamics, and actively working to improve them, you’ll build meaningful relationships with your customers, leading to greater, more effective collaboration and further pitches and briefs in the future.

Learn more about FeaturePeek Teams, our collaborative tool that supercharges deployment previews for webdev agencies and enterprises.

P.S. A big thank you to the super talented team at Sanctuary Computer for their help with this post!

FeaturePeek raises $1.8M in seed funding, announces FeaturePeek Indie

Wed, 13 May 2020 12:12:03 GMT

Today, we are excited to announce a major milestone in our company’s mission to shorten feedback loops for teams. We have raised $1.8 million in seed funding led by Matrix Partners and a select group of Angel investors. We are thrilled with this partnership, and are thankful to have the support of these fantastic investors as FeaturePeek helps provide the missing link in the frontend review process.

We started FeaturePeek in 2019 to solve a real-world problem that we felt while collaborating with product and design teams: scrambling at the last minute to integrate last-minute feedback into releases. By developing FeaturePeek and talking with our users, we know that teams need seamless tools earlier in the dev cycle to give effective feedback on frontend implementations. Unblocking stakeholders and shortening this feedback loop allows product, design, and engineering to save time and ship higher quality releases.

FeaturePeek creates supercharged deployment previews of your web frontend that you can share to quickly get feedback on your implementation in progress. A drawer overlay is added on top of your site that makes it easy for your reviewers to take screenshots with annotations, capture screen recordings, leave comments, create tickets on popular bug-tracking platforms, and more. You get this functionality just by deploying to FeaturePeek — no dependencies or code changes are needed.

Along with our funding, we are announcing a new product that we can’t wait for you to use.

👩‍💻 FeaturePeek Indie 👨‍💻

We are excited to launch a new entry-level product, FeaturePeek Indie. This command-line tool is the easiest way to try FeaturePeek’s deployment previews, without needing to setup a CI pipeline or install a GitHub app.

Best of all, it’s completely free and open source. We’re eager for developers to try this so they can easily share and get feedback on their work. Install the CLI with homebrew: brew install featurepeek/tap/peek, and be sure to leave any feedback via GitHub Issues.

FeaturePeek Teams

Our original solution that fits into your Continuous Integration pipeline is now known as FeaturePeek Teams. It’s the easiest way to explore the benefits of deployment previews without having to switch infrastructure. We’ve been busy listening to your feature requests — here are just a few that we’ve released in the last couple of weeks.

👨‍🎨 Unified drawer UI

The unified drawer brings new functionality and improved UX. Comments, page views, issues, and more are all presented together in a timeline view. You can file tickets to your connected integrations here, too.

📸 Crop and annotate screenshots

You can now crop and annotate screenshots right from your deployment preview and easily attach it to a comment.

🐛 File tickets with third-party integrations

You can now connect your Trello boards and Clubhouse projects to FeaturePeek and file new issues from the FeaturePeek drawer. Do you have suggestions for what issue tracking service to integrate with next? Let us know.

What’s next

With this funding round, we are able to bring FeaturePeek Teams and FeaturePeek Indie to market, and expand our presence in the developer community. These products represent big first steps as engineering tools made for working closer with design and product teams. Thank you so much for your support — we look forward to hearing how your team likes FeaturePeek.

How to import Mailchimp campaigns as a Gatsby source

Thu, 16 Apr 2020 12:12:03 GMT

Publishing your marketing newsletters on your website is a great way to increase the amount of content available on your domain automatically. We do this here at FeaturePeek – we publish our Product Update newsletter publicly so that each campaign can be forever preserved in the archives (here’s an example). We’ll show you how to do the same in this article.

The content is already written – don’t let it only be accessible via email inbox! The good news is that this is fairly trivial to set up if you’re building a static site with Gatsby.

Immediate benefits:

Improve SEO: Importing from Mailchimp as a source means that the content lives on your domain (we’re not talking about just embedding an iframe) so you can get all the SEO juice for the keywords you use in your email marketing.
Reduce newsletter churn: Give your readers an opportunity to preview the content of the newsletter they’re signing up for by having the content available to read on your website. Your subscribers will be less likely to unsubscribe when they can see samples of what you’ve sent out in the past.

Code sample: Our entire marketing site is open source, so you can see this code in action by visiting our repo.

Install dependencies

We’ll be adding the gatsby-source-mailchimp build-time dependency to do most of the heavy lifting for us here.

Since we only want a subset of each campaign’s HTML source (we don’t need the <head> tags from Mailchimp, for example), we’ll also need a DOM parsing library. We’ll be using cheerio in this article, but you can swap it out for another if you’d like, as long as it’s compatible with Node.js (the native DOMParser would be ideal, but it’s only available to browsers).

yarn add gatsby-source-mailchimp cheerio

Create a Mailchimp API key

After logging in to Mailchimp, click your avatar in the top right and then click Account in the resulting dropdown menu. From there, click on Extras > API keys.

Click the “Create A Key” button to generate a new API key.

You should rename the Label while you’re at it so that you and your teammates know what the key is correlated with – we named ours gatsby-source-mailchimp.

Save the Mailchimp API key as an environment variable

We’ll want to save the API key as an environment variable so that we don’t check the value into version control. Anyone can read or write data to/from your Mailchimp account with this API key, so you want to make sure that you’re careful with it.

You probably have a .env.development and/or .env.production files in your project root if you initially followed Gatsby’s docs – these gitignore’d files contain your project’s environment variables. Save a new line in them with the following:

MAILCHIMP_API_KEY=<YOUR_KEY_GOES_HERE>

Don’t forget to add this value to your servers and continuous integration platforms, as your build won’t build correctly without it.

Configure the Gatsby plugin

Tell Gatsby that you’d like to use the gatsby-source-mailchimp plugin in your gatsby-config.js file. This will read from the MAILCHIMP_API_KEY environment variable that you defined earlier.

// gatsby-config.js
module.exports = {
  plugins: [
    // ...
    {
      resolve: "gatsby-source-mailchimp",
      options: {
        key: process.env.MAILCHIMP_API_KEY,
        // replace `us20` with the value in your Mailchimp dashboard URL
        rootURL: "https://us20.api.mailchimp.com/3.0"
      }
    }
    // ...
  ]
}

Create the CampaignPost template component

This component will be what renders when someone loads an individual campaign post page. You might recognize the format of this component if you followed any of the Gatsby blog starters – it’s very similar to the BlogPost template component.

We’ll be checking that status === 'sent' and post.send_time !== 'Invalid date' in order to prevent accidentally publishing draft campaigns that haven’t been sent out yet.

// src/templates/CampaignPost.js
import React from "react"
import { graphql, Link } from "gatsby"
import cheerio from "cheerio"

import Layout from "components/Layout"
import SEO from "components/Seo"

export default function CampaignPost(props) {
  const post = props.data.mailchimpCampaign
  const siteTitle = props.data.site.siteMetadata.title
  const { previous, next } = props.pageContext

  // we don't want the full post.html -- just what is in the body container
  
  const $ = cheerio.load(post.html)
  const bodyTable = $('.bodyContainer').html()

  return (
    <Layout title={siteTitle}>
      <SEO
        title={post.settings.title}
        description={post.settings.preview_text}
      />
      <div style={{ margin: 'auto', maxWidth: 600 }}>
        <Link href="/product-updates">← All product updates</Link>
        <h1>{post.settings.title}</h1>
        {post.send_time !== 'Invalid date' && <p>{post.send_time}</p>}
      </div>
      <div id="campaign" dangerouslySetInnerHTML={{ __html: bodyTable }} />
      <ul>
        <li>
          {previous && previous.status === 'sent' && previous.settings.title && (
            <Link href={`/product-updates/${previous.campaignId}`} rel="prev">
              ← {previous.settings.title}
            </Link>
          )}
        </li>
        <li>
          {next && next.status === 'sent' && next.settings.title && (
            <Link href={`/product-updates/${next.campaignId}`} rel="next">
              {next.settings.title} →
            </Link>
          )}
        </li>
      </ul>
    </Layout>
  )
}

export const pageQuery = graphql`
  query CampaignPostById($slug: String!) {
    site {
      siteMetadata {
        title
        author
      }
    }
    mailchimpCampaign(campaignId: { eq: $slug }) {
      html
      settings {
        preview_text
        subject_line
        title
      }
      campaignId
      send_time(formatString: "MMMM DD, YYYY")
      status
    }
  }
`

Create ProductUpdates page component

This page serves as the collection page for all of your campaigns. In this example, it’ll be served from the /product-updates route.

// src/pages/product-updates.js
import React from "react"
import { graphql, Link } from "gatsby"

import Layout from "components/Layout"
import SEO from "components/Seo"
import JoinMailingList from "components/JoinMailingList"

const reverseChronologically = (a, b) => 
  new Date(a.node.send_time) < new Date(b.node.send_time) ? 1 : -1

export default function ProductUpdates(props) {
  const { data } = props
  const siteTitle = data.site.siteMetadata.title
  const campaigns = data.allMailchimpCampaign.edges

  return (
    <Layout title={siteTitle}>
      <SEO title="All product updates" />
      <h1>FeaturePeek product updates</h1>
      <JoinMailingList />
      <h2>Archive</h2>
      {campaigns
        .sort(reverseChronologically)
        .map(({ node }) => {
          const title = node.settings.title
          return (
            <div key={node.campaignId}>
              <small>{node.send_time}</small>
              <h3>
                <Link href={`/product-updates/${node.campaignId}`}>{title}</Link>
              </h3>
              <p>{node.settings.preview_text}</p>
            </div>
          )
        })
      }
    </Layout>
  )
}

export const pageQuery = graphql`
  query {
    site {
      siteMetadata {
        title
      }
    }
    allMailchimpCampaign(
      filter: { 
        status: { eq: "sent" }, 
        settings: { 
          title: { ne: "" } 
        } 
      }
    ) {
      edges {
        node {
          settings {
            preview_text
            subject_line
            title
          }
          campaignId
          send_time(formatString: "MMMM DD, YYYY")
          status
        }
      }
    }
  }
`

Extend createPages

Finally, we need to create the graphQL query to pull the data from the Mailchimp source.

If your Gatsby project already contains a blog, your createPages method in gatsby-node.js is probably already in use. You’ll need to combine what you already have with what is written in detail below in order to iterate over both your blog posts and Mailchimp campaigns.

// gatsby-node.js
exports.createPages = ({ graphql, actions }) => {
  const { createPage } = actions
  const CampaignPost = path.resolve(`./src/templates/CampaignPost.js`)

  return graphql(`
    {
      allMailchimpCampaign {
        edges {
          next {
            campaignId
            settings {
              preview_text
              subject_line
              title
            }
            status
          }
          previous {
            campaignId
            settings {
              preview_text
              subject_line
              title
            }
            status
          }
          node {
            html
            settings {
              preview_text
              subject_line
              title
            }
            campaignId
            send_time
            status
          }
        }
      }
    }
  `).then(result => {
    if (result.errors) {
      throw result.errors
    }

    // Create product update pages
    const campaigns = result.data.allMailchimpCampaign.edges

    campaigns.forEach((campaign, index) => {
      const previous =
        index === campaigns.length - 1 ? null : campaigns[index + 1].node
      const next = index === 0 ? null : campaigns[index - 1].node

      createPage({
        path: `/product-updates/${campaign.node.campaignId}`,
        component: CampaignPost,
        context: {
          slug: campaign.node.campaignId,
          postPath: `/product-updates/${campaign.node.campaignId}`,
          previous,
          next,
        }
      })
    })

    return null
  })
}

Rejoice in the glory of automation

That’s all there is to it! Now the next time you rebuild your site, your campaigns will be pulled from Mailchimp and built as static HTML pages. You can check out how ours look here.

Remember, the source only gets queried at build time – so when you mail out a new newsletter, you’ll have to rebuild your Gatsby site to pick up the content and publish on your website.

Thanks for following along!

One closing note: While I was writing this article, I verified that the code samples worked as expected by building the deployment preview of this blog post on FeaturePeek. It was super useful to confirm that the whole idea behind was behaving correctly on a server besides my local machine.

We use FeaturePeek on featurepeek.com (meta) to iterate faster during development. Our blog (and entire marketing site for that matter) is open source on GitHub, so you can take a peek at the preview environments that deploy on our open pull requests.

How to make your team still feel like a team while being remote

Thu, 16 Apr 2020 12:12:03 GMT

Well, we’re just over a month into shelter in place and it’s it’s starting to feel like the initial panic of “well, what do we do?” has worn off a bit. Teams are meeting regularly on Zoom, but a new set of challenges exist.

We don’t know how long this will last, and even once sheltering in place is over, life most likely won’t go back to normal for quite some time, or possibly ever. The norm has changed and the past month has definitely shown that more teams will go fully remote in the future, pandemic or not.

This pandemic has proven that remote work isn’t just the way of the future. It’s happening now, and there are plenty of positives. Technology has made it easier to connect, and educational programs are adapting. The world has changed, and it will never fully go back the way it was, nor should it just return to the status quo.

At first glance, it might seem like teams have it figured out. Sure, you use Zoom for team meetings, and your team is still producing solid work, but how about the things that you can’t measure? How does your team feel? Are ideas still free flowing between team members? How is company culture maintaining or changing?

Here are some ideas that have helped me and my team still feel like a team while staying remote.

Don’t over-Zoom

Zoom has had a massive increase in popularity over the past month and for good reason. However, with teams scrambling to maximize video conferencing, they can quickly become counterproductive if no thought is put into best practices.

Save Zoom meetings for presentations or information distribution meetings, and don’t feel the need to have every meeting be an all-hands video call. It’s also important to not expect your team to spend all day on Zoom. If your team didn’t spend their whole day in the office in meetings, don’t expect them to be on a Zoom call all day. People still want to put their headphones on and be left alone sometimes. The idea that an teammate has a camera on most of the time doesn’t promote autonomy or personal ownership, and can show a lack of trust.

Figure out how to brainstorm remotely

Nothing will ever replace getting in the same room and jamming on an idea, but there are some great tools that are helping to bridge that gap without just being a video conference platform.

Here’s how we do it at Feature Peek.

Tandem - great app for workspace sharing. easy to jump into a spontaneous chat
Slack - Pro tip, make specific channels for work and non work conversations. #project-chat, #water-cooler, etc
Slite - Great for building a library of onboarding documents, better than a team wiki, great for collaboration.
Miro - Digital whiteboard for brainstorming
There.pm - Simple way to keep track of your teammate’s timezones
Donut - Slack add on to make team bonding easier
Zync - Avoid calendar Tetris by having Zync intelligently schedule meetings.
FeaturePeek - Great for front end feedback and collaboration (shameless plug)

Make yourself available to be a rubber duck

If you ask my team, I probably use the Rubber duck debugging method more than anyone else at FeaturePeek. Being at home has made that slightly more difficult, but making yourself available for a quick 5 minute chat can unblock you technically, and maintain the feeling of team collaboration and spontaneity.

My favorite debugging tool

Perfect the daily stand-up

Daily stand up meetings to identify priorities, dependency conflicts, or areas of collaboration can be highly effective when run well. In my experience, however, they sometimes tend to devolve into an uninspiring summary of the current sprint board. And with quarantine inevitably making the days and weeks blend together, it’s even harder to make a daily stand up meeting worthwhile.

Adding a framework to your daily standup can keep it interesting and not just make it about what bugs you fixed yesterday. At FeaturePeek, our daily stand ups have every team member answering these questions:

What are your top priorities today?
Did you discover anything interesting or unexpected yesterday?
What challenges or roadblocks do you need help with?

With this simple framework, our stand-ups keep us all on the same page, and start the day with good jumping off points for collaboration and areas we know we should focus on.

Be there

It’s becoming clear that being in the office is less about the work and more about the things you get for free. I’m not talking about the granola bars and La Croix — I’m talking about the personal moments of asking how someone is doing to understand what’s happening in their world, in their heart. Sure, this is important for building good team dynamics, but more importantly, it’s a major aspect of life that everyone is missing right now.

Don’t discount 1-1’s

1-1’s are more important now than ever. Don’t neglect them and do what you can to make the most of them. Rather than being stuck at my desk like an ordinary Zoom conference, I’ve found that I am more present in my 1-1s if I take them while on a walk around the neighborhood or the park. Getting outside and making that intentional time is crucial to connect with your team. And when you are in your 1-1, treat it like you would if you were in person. Sure, you should acknowledge how weird this is and the news of the day, but don’t forget to still manage performance, give feedback, and most importantly manage career growth. Just because the world feels like it’s on pause doesn’t mean your employees’ career goals are, and yours shouldn’t be either.

Be patient, be kind

This situation isn’t normal, so don’t act like it is. Everyone is experiencing their own emotions, sense of loss, fear, and anxiety. Everyone is adjusting to a work/life balance that all just became one bowl of soup that you eat on your couch while wearing the same sweatpants for 3 days. Take it slow and be kind. Not everyone is going to adjust as quickly as you may expect, so don’t expect 100 percent productivity from your team. This is definitely a time where it’s more about quality over quantity. So make sure to focus on finding the humanity in this situation we are all in, and bring that energy to your team.

Do it for your culture

You put the time and intention into building your team and company culture, now is the time to use it or lose it.

Keep doing the things that make your team unique. All the funny, silly, and unique touches go a long way and are important to remember. For example, at FeaturePeek we name all of our releases after Nicolas Cage movies, and watch the trailers before we plan our sprints. We still watch them before the meeting, but just independently on our own machines rather than in one room together. We still make sure to save a few minutes to laugh about it together before jumping back into the meeting.

Show off

Find a good way for your team to give a demo of what they are working on. Having an ‘over the shoulder’ review is vital to the dev cycle. Screen sharing or collaborating within a FeaturePeek environment can make for a smoother transition to virtual frontend review. Try an end of the week demo where everyone gets a turn showing off their work. It’s a great opportunity for your team to feel rewarded for their efforts.

I’d love to hear about how your teams are adapting to this new normal. Feel free to shoot me an email or connect with me on LinkedIn.

The 8 Best Tools For Code Review In 2020

Fri, 06 Mar 2020 12:12:03 GMT

We love great code reviews. They dramatically improve the quality of your code, which ultimately means better and more reliable products.

What we don’t love about code reviews is how long they take, with many pull requests being painfully slow to approve. We shared a few tips to speed code reviews up here, but another big factor is having the right tools for the job.

In this article we’ll share some of the best tools we’ve used during the code review process. Many of the tools listed here are available through the GitHub Marketplace, and we’ve given the pros and cons of each one below.

AccessLint

How accessible is your software?

Chances are, you probably don’t know for sure. The sad truth is that while web accessibility standards are well documented, they’re rarely part of the code review process.

That’s why we love AccessLint, which automatically runs a series of accessibility tests and comments on your pull request with easy suggestions to resolve them. This includes major accessibility features, as well as those that benefit those with temporary conditions (like a broken arm) or more minor ailments (like bad eyesight).

If you’re not already on your accessibility, you really need to be. In many countries, this is now a legal requirement.

In the US, there have been various lawsuits against inaccessible websites that do not comply with ADA guidelines. In the UK, web accessibility is protected by the Equalities Act.

Pros
- Gives instant WCAG 2.0 accessibility feedback for common accessibility issues
- Available through GitHub Marketplace, so can be added instantly
Cons
- Not a comprehensive review and only covers basic issues
- Limited file type support (Haml, HTML, ERB/Rails)
Pricing
- Free for all open-source public projects
- Free for educational institutions for public and private projects
- $49/month for unlimited public and private projects

Imgbot

When you are focused on shipping code and reaching deadlines, it’s easy to forget to optimize images.

But smaller images mean a better experience for your users, with fast load times, higher conversion rates and reduced bandwidth costs. So it’s really important not to overlook this.

Imgbot is a simple tool that handles losslessly compressing all the images in your repositories. There’s no fancy stuff going on here, just a super simple and mega effective tool to cover off this specific review necessity.

Pros
- Automatically optimizes images losslessly, but can be set to more aggressive compression if required
- Once set up, no interaction is required - just approve the incoming merges.
Cons
- Pricing is high for small teams
- Would love to see support for video files in future
Pricing
- Free for open source projects
- $10 per month for personal projects
- $30 per month for professional projects

LGTM

LGTM is a code analysis platform that focuses on finding 0-days (an unaddressed software vulnerability) and preventing critical issues in your product.

If an issue is detected by their 1600+ analyses, it is automatically flagged on the pull request to be resolved or mitigated.

Their security analysis is unparalleled in the industry, with a dedicated team of security researchers who have found 107 CVEs to date in high-profile projects like UBoot, Apache Struts, the Linux Kernel, Memcached, VLC, and Apple’s XNU.

Example issues detected includes regular expression injection, XSS detection, and poor code quality leading to security issues.

Pros
- Wide support for programming languages, including C, C++, Java, Javascript, and Python
- High level of detection of vulnerabilities and important code problems
Cons
- No Go support - try Deep Source below for this

DeepSource

Used by companies like NASA, Uber, and Slack, DeepSource detects documentation coverage issues and security vulnerabilities automatically.

Example issues detected include:

If you use a module but fail to include it in your requirements management
Static Application Security Testing (SAST) issues
Sensitive information committed to the repository instead of a private environment file

DeepSource automatically adds annotations and comments to pull requests, making it easy to see issues and ensure good security code. This makes the entire code review process quicker and ensures higher code quality across the project.

Pros
- Gives instant security feedback in a friendly way
- Easy-to-use web interface
Cons
- Limited to Python and Go
Pricing
- Free for all open-source public projects
- For private projects, from $12 per month

Codelingo

Once you’ve set standards for code quality, you need to check that they are being met. Most teams use a generic linter to do this, but there is a better way.

Enter Codelingo — this tool allows you to define and check your rules programmatically in a codelingo.yaml file.

The main advantage of Codelingo over generic code quality tools is that you can flexibly write rules that actually work for your team, rather than being limited by a generic linter.

Should the rules not be met in a pull request, Codelingo automatically comments on the pull request and notifies the contributor to be fixed. Simple.

Pros
- Can define bespoke code quality rules
- Automatically resolves minor code quality issues
Cons
- Only supports PHP, Python, Go and C#
Pricing
- Generous free plan for public repositories
- $15/month per organization member, with assistance to write rules for your most significant issues

DeepScan

DeepScan is an advanced static analysis tool that supports JavaScript, TypeScript, React, and Vue.js.

It automatically identifies possible runtime errors and potential quality issues, going beyond what ESLint can do by truly understanding the data-flow of your entire application.

DeepScan also provides helpful metrics on team member performance and how closely they follow code standards, helping managers provide constructive feedback.

We also love their grading system, which assigns your projects a simple grade of either “Poor”, “Normal”, or “Good”.

Pros
- Specialist tools for JavaScript, TypeScript, React, and Vue.js projects
- A simple grading system for feedback
Cons
- Limits on language and library support
Pricing
- Free for open source projects
- From $15.96 per seat per month

CodeScene

CodeScene is a behavioral code analysis tool that analyzes behavioral data as recorded in version-control systems. This lets CodeScene uncover both organizational information such as knowledge distribution, inter-team coordination bottlenecks in code, as well as prioritizing technical issues based on the estimated return on investment if the findings are addressed.

Pros
- Explore the efficiency of your organization with respect to Conway’s Law.
- Detect sub-systems with low team autonomy that become productivity bottlenecks.
- Measure the technical risk when a key developer leaves the project.
Pricing
- Analyze up to 5 projects for free
- Unlimited git repos in analyses starts at $249/month

FeaturePeek

Before we go, there is one more tool for your consideration — our very own FeaturePeek.

One of the most tedious parts of the code review process is running your peers’ branches locally to confirm that their code works as expected.

The truth is, many times this step simply just gets skipped. And non-technical stakeholders (such as a designer or a product manager) with no knowledge of git or frontend development definitely don’t do it.

With automated deployment previews for every pull request, reviewers can see the code working, just by clicking a link, before any code gets merged into the default branch.

What sets FeaturePeek apart from other deployment preview services? FeaturePeek overlays collaboration tools on top of every environment to empower your reviewers leave great reviews. The collaboration tools include commenting, filing new issues with bug templates, screen recording, pixel measurement, and more. This functionality comes standard just by deploying to FeaturePeek — no modifications to your frontend stack required.

Like all the tools in this blog post, FeaturePeek plugs into GitHub seamlessly, so getting up and running just takes a few minutes.

You can try FeaturePeek for free for 14 days by creating a new account here.

Pros
- Ephemeral, on-demand deployment previews for every frontend pull request
- Floating widget on every preview makes it easy for your team to leave feedback
- Hosting provider / PaaS agnostic, works with static and dockerized frontends
Cons
- Let us know if you can think of any!
Pricing
- Free for public repos
- $19/user/month for private repos ($16/user/month for annual commitment)

The subtle art of giving great code reviews

Thu, 06 Feb 2020 12:12:03 GMT

Peer code review is the biggest and best thing you can do to improve the quality of your code.

So much so, that in the book Code Complete, Steve McConnell gives real-world examples of the dramatic impact code review can have:

AT&T reported a 14% increase in developer productivity and a 90 percent decrease in defects after they introduced reviews.
Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by fixing defects at an early stage.
Aetna Insurance Company was able to decrease its development resources by 20%.

Having a second pair of eyes give your work a once-over can help prevent mission-critical bugs from entering into the wild. And you can learn a thing or two along the way.

So, what exactly is a code review?

A code review happens once a developer has submitted a contribution to the project.

This is known as a ‘pull request’, and you can read a detailed definition and learn how to use them effectively in our previous article.

Before this contribution can be added to the project, other team members will review the code, checking for issues, suggesting improvements and ensuring overall product quality.

This code review can take place whether the team feels most comfortable. It could be comments on Github, a chat on Slack, via Skype or in person.

What are the benefits of a code review to your team?

The benefits of code review are obvious — you’ll discover bugs, improve code quality and build better projects, too.

But the major benefits of code review are about people.

Sure, you can use testing, but the statistics seriously speak for themselves — the average defect detection rate is only 25% for unit testing, 3% for function testing, and 45% for integration testing.

Therefore, your code reviews must never be entirely automated. Instead, try incorporating some of these ideas into the process:

Sharing Knowledge: When programming, there are often several ways to solve a problem. Reflecting on why this particular approach was chosen reveals hidden knowledge. For example, the reviewee might have a different understanding of the architecture of the application, a superior knowledge of the technology being used or is lacking a key skill — all of which are opportunities to share knowledge.
Better Estimates: When estimates are wrong, code reviews are an opportunity to see where the hidden complexities or difficulties were. This leads to more accurate estimates in the future.
Mentoring: Code reviews can uncover areas for improvement and self-development, which is invaluable to any reviewee. It can also be valuable for the reviewer, who will learn by teaching others.
Check requirements: Code reviews are the perfect opportunity for agile teams to return to the user story acceptance criteria and check that requirements are met. For added insight, involve stakeholders, designers, and product managers with review tools like FeaturePeek.

How to give great code reviews

Always give constructive feedback

Nobody likes being criticized, especially by their fellow team members. For a code review to be great, the reviewer must balance being positive with avoiding code defects.

The first step is to remove the stigma from reviews. Bugs should not be seen as negatives, but instead as an opportunity to teach, fix bad habits and to improve code quality.

This means that the number of errors produced by each team member should not be tracked, nor used in performance evaluation reviews.

The next step is to reframe the code review as a coaching opportunity. Instead of harsh criticisms, employ the Socratic method. The most effective way to do this is to encourage self-evaluation by asking questions, paving the way while helping them discover it for themselves. Just like this:

Critical Feedback 🙀	Constructive Feedback 😸	Outcome 😻
"Why doesn't this have test coverage?"	"How could more test coverage benefit us as a team?"	Improved understanding of test coverage
"This function is terrible / complicated!"	"How could we improve this function to make it simpler?"	Future functions will be easier to understand
This doesn't match the design!	"Looks good, but it's different from the design — was there some complexity in implementing the design as specified?"	Identify issues with requirements or skills

If one of your reviewers is struggling with constructive feedback, coaching or relationship training might also be appropriate — the goal is to always keep your team feeling motivated and ready to do their best work!

Agree standards and follow them

Positive peer pressure is a powerful tool. As developers know that their peers will see their code during the review process, allow them to improve their code before submitting it. After all, we all want to look good in front of our team members!

So, follow these steps to ensure that each reviewer is doing the best they can:

Agree a definition of ‘good code’ with your team. This might include formatting, commenting, security considerations or other considerations unique to your industry or team. Use a linter if you aren’t already. It should also include a summary of how to make a pull request that can be reviewed quickly — see our guide to authoring better pull requests.
Include a ‘good code’ checklist in every pull request. The submitter must complete this pull request.
The reviewer should check the code to ensure this checklist is accurately completed.

Always be timely

Code reviews are blockers — until a review has been completed and the code merged, the next stage cannot be completed. If issues are identified, the developer might need to redo work, slowing development further.

Resolve this issue by agreeing to complete code reviews within a certain amount of time. For example, you could agree to have the code review completed and pull requests merged within 2 business days.

Of course, a goal without a plan is just a wish. Therefore, make plans to ensure success, such as:

Allow your reviewers to prioritize reviews over other tasks when required, and never penalize them for missing deadlines as a result.
Assign more reviewers as needed.
Reduce the number of approvals required. Some teams require 2 reviewers to approve before merging — if this is a blocker for your product, ask yourself: is this always necessary?
Measure the time taken to complete pull requests and seek feedback and suggestions for improvements regularly.

So, are you ready to give great code reviews?

Now you know how to give great code reviews that improve code quality and improve team productivity, your next step is to automate and systemize where possible. Try adding FeaturePeek into your review workflow to reduce the friction of doing peer code reviews today.

Why are so many organizations slow to approve pull requests?

Thu, 23 Jan 2020 12:12:03 GMT

Pull requests can be notoriously cumbersome and slow to approve, causing a ripple effect of problems as a result.

What exactly is a pull request, and why can they be so tricky for developers to push through? Most importantly, what can be done to minimize the problem?

What exactly is a pull request?

Put simply, a pull request is how developers submit their contributions.

At its most basic form, a pull request contains the changes made to the code of the project. The best pull requests will contain a description of what has changed, why those changes have been made, and facilitate discussion between developers, product managers, and designers.

The pull request can then be code reviewed, checked for bugs and feedback given. Finally, the code is given the green light, and the changes get merged to the master codebase.

At least, this is how it should work in an ideal world.

In the real world, though, software is messy and pull requests can get complicated.

They can even conflict with each other, preventing the code from being merged into the main project. This results in a delay in the pull request from being approved, which ultimately leads to a huge blocker for the project overall.

Worse still, there’s a direct correlation between the duration of a pull request and business spend. Making it quite a costly issue to have.

But why does this happen? And is there anything that developers can do to limit this risk?

Why can pull requests take a long time to approve?

The three most common reasons for slow pull requests are:

1. They are difficult to deploy

It is often very time-consuming for a reviewer to download the branch, make sure it works locally, and check that everything works as expected.

This is particularly true for non-technical stakeholders (such as a UXer or a product manager) who might not even know how to run the application locally.

This is where review tools like FeaturePeek shine. With automated deployment for every pull request, reviewers can see the code working instantly on a web page and give feedback quickly. Even better, it’ll automatically remind the reviewer on Slack that they need to approve the pull request, to avoid unnecessary delays.

2. There are merge conflicts

Merge conflicts occur when two branches have made changes to the same line in a file, or one branch has deleted a file. There’s no two ways about it: merge conflicts are bad news when it comes to approving a pull request.

The good news, though, is that they can be avoided by following these 3 simple rules:

Keep the changes in your branch as small as possible — With fewer code changes, it is less likely conflicts will occur. Many small changes are better than few large changes.
Rebase from master when it changes – This updates your branch with the latest version of the master, so you can resolve any conflicts locally. This essentially rewrites the order of the commit history, so if you’ve already pushed your branch, you’ll have to force-push for the change to land upstream.
Review pull requests faster and more frequently — The longer a pull request stays open, the more likely the code will be behind merged changes.

3. You have bad pull request etiquette

If your team is submitting complicated pull requests that are difficult to understand, you’ll lose productivity quickly. The good news is, there are some relatively simple rules that all developers can follow to make sure that their pull request etiquette is optimized for success.

In a nutshell, the best pull requests are:

Submitted frequently — Submitting pull requests frequently means that likely only a small amount of code has changed, making it simpler to explain and less likely to have unintended impacts on other areas.
As small as possible — Breaking down a big change into many smaller requests makes the code much easier to review. There is no rule for the number of lines of code, as every project is different, but agree on a reasonable limit with your team.
Well documented — Pull requests should contain summary notes for the reviewer on what has changed. This makes it much easier to review.
In line with the Single Responsibility Principle — Code changes should aim to only solve one problem. If a piece of code affects a lot of the rest of the code in the project it becomes very difficult to test, slowing down the review process.

It helps a lot to have a preview link in every pull request, so that reviewers don’t have to run your code locally.

How can you speed up pull requests?

If your pull requests take a long time to review and it’s slowing development and innovation, try these 6 quick tips to unlock increased developer productivity:

1. Automate deployment

When a pull request is made, use an automated deployment tool to make an instant preview of the change available. This also enables non-technical stakeholders to see changes instantly, helping to keep your team on track.

2. Write great commit messages

Commit messages tell the story of how the code was written and what issues were overcome. By making these detailed, it’s easier to understand the whole pull request and therefore review it much more quickly.

A great commit message has a subject that briefly explains what you did and a body that explains what you’ve done, how you’ve done it and why you did it in that way.

If you haven’t already, decide with your team if you’d like to follow a commit message convention. This will help automatically decide release version numbers by following semantic versioning.

3. Set and enforce good pull request etiquette

In the next planning meeting or sprint retrospective, write down a few simple rules and agree to hold each other to account (Remember: a good pull request is small, well-documented and follows the single responsibility principle.)

If pull requests continue to be slow, ask your pull request approvers to always reject pull requests which don’t meet these rules. You’ll lose productivity in the short term, but set good behaviors for the future.

4. Detox your code reviews

Code reviews are an essential part of the pull request approval process, but can be toxic and painfully slow. You can detox code review by:

Peer review — Many organizations only allow senior developers or managers to review code, creating a gatekeeper. Make code reviews feel more collaborative by encouraging peers to review each others code instead.
Being constructive — It goes without saying: don’t only say negative things in a review, even if the code must be rejected. Find the good parts of their code to celebrate, and frame criticism constructively as an opportunity for growth.
Automation — Set code standards and enforce them automatically with code quality analysis tools. This provides instant code review against defined standards, improving code quality without an awkward code review meeting.

5. Add more reviewers

If you’ve made all the changes above and pull requests are still slow, it might be an issue with your reviewers. Ask your existing reviewers how you can help them review more quickly — it might be a simple matter of not having enough time or the right frontend review tools in your workflow.

Code-review-as-a-service tool PullRequest recommends having at least two reviewers per PR: one who has knowledge of the particular code being changed, and one who doesn’t (a neutral third-party). It’s even recommended to have someone review a language they’re unfamiliar with over not having anyone review at all.

6. Avoid merge conflicts

Resolving merge conflicts drains time, enthusiasm and productivity from developer teams. Most are unnecessarily caused by bad pull-request etiquette, so following the other tips in this article should reduce them.

Are you ready to fix your pull request bottlenecks?

Once you’ve encouraged your team to follow good pull request etiquette, document clearly and fix toxic review habits, the next step is to automate as much of the pull request process as possible. Try adding FeaturePeek into your review workflow to reduce the friction of approving pull requests.

Where should your team review your frontend changes?

Tue, 26 Nov 2019 12:12:03 GMT

TL;DR: Ask for visual feedback on your new frontend features in isolated remote environments. You can quickly achieve this setup with FeaturePeek, a new service that enables frontend deployment previews for static and containerized web apps regardless of cloud provider.

You’ve just finished developing a new feature for your web app, and you’re ready to get feedback from the rest of your team. You’re pretty sure it’s what your designer intended in their prototypes, although you had to take a few liberties – you did some guesswork when mockups for tablet breakpoints weren’t supplied, and you had to come up with a workaround or two due to a technical constraint. You want to get some feedback on your work before rolling out the feature to production.

Engineers can leave feedback on GitHub or similar during code review, but this part of the product development lifecycle isn’t accessible to those in non-code-savvy roles. What’s the best way to open up your work to the rest of your team?

Let’s explore some options. Ideally, we’d want a solution that:

Reduces the duration of feedback loops between cross-functional teams. You should be able to send a link for someone to review as soon as you are ready, not as soon as your internal infrastructure allows you to be ready.
Circumvents performing code review on the same feature twice. You shouldn’t depend on your developer peers to finish reviewing your code before you’re able to share your work with someone else on your team. If you receive feedback to make changes, your peers will have to do code review again for what is essentially the same feature.
Requires as little maintenance and code changes as possible. You shouldn’t have to spend time building infrastructure to support a basic review process. If possible, you’d like to lean on an existing tool that has already solved this problem.

In person (or screensharing) 👎

While rolling up to your colleague’s desk (or virtual desk if your team is remote) can clear up quick clarifying questions, it poses problems when trying to gather detailed critique. Common pitfalls include:

Scheduling common availability is difficult. What if your reviewer is in a meeting? Or working heads-down on an upcoming deliverable? You both need to have uninterruptible availability to get their feedback synchronously. Trying to get two people’s schedule to sync up is too time-intensive and breaks their flow, especially in fast-moving startups.
You miss out widening your surface area of test cases. When you show someone a feature that you’ve coded up on your own machine, you are forgoing the opportunity to apply variance to it. How does it respond to production data? Does it require a font that is only installed locally? How does it behave when you’re logged in under a different user account? You’ve tested responsiveness in Chrome DevTools — how about on a real device?
You become responsible for taking notes of reviewer feedback. You can jot reviewer feedback down while in person, or create a quick todo list, but ad-hoc review that exists outside of formal tools is undocumented and bound to slip through the cracks.

The productivity benefits of asynchronous communication are clear. You should avoid collecting feedback synchronously whenever possible.

Local dev server tunnel 👎

How about opening a tunnel to your local development server’s running port? You could use ngrok to expose a port so that someone outside of your LAN could access your local dev server.

There are lots of problems with this approach:

Your machine must be powered on and online. As soon as you close your laptop, the bridge to your dev server is terminated.
You can’t checkout another branch while the tunnel is live. If you wanted to show someone something on a specific branch, you’d have to stay on that branch. This means that you are blocked from working on anything else.
Your reviewers aren’t getting a production build. Instead, what they’re seeing is the development build, which isn’t as performant as what eventually gets pushed to production.

Local build during code review 👎

As a developer, you’re familiar with conducting code review when your coworkers open pull requests. The code may look correct… but does it work? A good way to test if it works is to run the code yourself. However, to do that on your own machine requires you to jump through a few hoops. The following flow should look all too familiar:

Stop what you’re doing
Stash any unstaged changes
Fetch from origin
Checkout their branch
Install dependencies (and potentially restart your development server)
➡️ Actually verify the new feature and provide feedback
Checkout your original branch
Pop your git stash
Reinstall dependencies (and potentially restart your development server)

You can see the trouble with this — there are many steps you must accomplish before and after verifying that make the task a tedious effort. Most of the cognitive load of verifying someone else’s feature on your machine comes from stopping what you’re doing.

Furthermore, unless your entire team is fluent with git, this option is only available to developers. What about the non-developers on your team?

Staging or QA server 👎

Your continuous integration pipeline builds the latest changes from a protected branch in your git repo, and deploys the build to an internal server. It seems like a safe place to review new features, because it’s a close representation of what production will look like when it eventually goes out the door. However, there are some problems with using this traditional method:

Feedback from reviewers causes more code review. When you ask someone for feedback on your work, they will most likely respond with at least some critique, which will require code changes to fix. Your developer peer must be asking themselves, “Didn’t I already review this feature?” You should aim to have every new feature only go through code review once to avoid bottlenecks in your workflow.
Other developers could break your changes. The problem with this approach is that other developers on your team could inadvertently merge a change of theirs that breaks the functionality of your new feature. By passing around a link to an environment that gets fed from top-of-tree, you aren’t guaranteeing that your feature is isolated. By the time your reviewer tests your new feature, a part of it (or the whole thing!) could not function as intended, even though it worked when it was on its own branch. Not only does this waste your reviewer’s time, but it causes them to think that you incompetently didn’t perform a basic test of your own work. A better option would be to guarantee that the code you push is the code your reviewer tests — this is what we mean when we say you should test features in isolation. A staging / QA environment is great for testing a whole release, not individual features.

Feature environments 👍

The best place to review your feature is on the feature branch itself. Ideally, as soon as you push your branch to your repo, your CI builds an image that is deployed to a dedicated host. Feature environments are automatic and ephemeral, orchestrated via webhooks from your repo.

Asynchronous. No scheduling calendars, syncing up for in-person walkthroughs, or tunneling to your local dev server.
Instant. No need to wait for unit tests or code review to pass before you can get feedback from designers, marketers, or other stakeholders on your team. No need to checkout branches and install dependencies just to verify your coworker’s code. Shorten feedback loops with your reviewers so that you don’t need to ask your developer peers to review the same feature multiple times.
Accurate. You can find more issues ahead of time by running your code on a machine that isn’t your local dev box. Rest assured that what you see is what you will deploy, because your build comes from your CI server.
Isolated. Since the feature environment spins up from your branch, no one else will accidentally break your feature. Reviewers won’t be upset that your feature clearly doesn’t work.

Imagine every pull request in your repo having its own live, up-to-date environment. Links to the environment are posted as a comment in your pull request, and to a Slack channel. As soon as your feature gets merged, the environment gets torn down.

Feature environments as a service 👍👍

Developing the infrastructure in-house to support feature environments yourself takes developer time and ongoing maintenance. You should instead focus on building the product(s) that are core to your business.

FeaturePeek is a feature-environments-as-a-service platform that integrates with your GitHub organization. In just a few clicks, you can start building on-demand feature environments for every frontend pull request. On top of that, FeaturePeek overlays feedback and collaboration tools over every feature environment, so your reviewers can leave comments, file bugs, attach screen recordings, and more — all from the context of the environment itself.

We launched to solve this problem that we’ve seen so many small- to medium-sized companies encounter. Start a free trial today and let us know what you think.

Deployment previews for UI/UX teams · FeaturePeek

FeaturePeek has joined Netlify!

What this partnership means for FeaturePeek

What this means for FeaturePeek customers

Next steps

How FeaturePeek manages security

1. FeaturePeek deployment previews are private by default

2. We never store your source code on our side

3. We never write code directly to your repo

4. We use HTTPS everywhere

5. Your app is completely isolated from other users’ apps

6. FeaturePeek environment variables are encrypted at rest

7. We use a password manager (and you should too!)

Learn more

FeaturePeek CEO Eric Silverman on Beginning your career in Software Engineering (video)

How did you get started in software engineering?

Why learn software fundamentals?

What jobs should new developers apply for?

Why are interpersonal skills so important on software development teams?

How can new developers gain experience?

Beginning your career in Software Engineering (full video)

Getting started in DevOps, CI pipelines, and setting up your first GitHub Actions (video)

Automate and Deploy with GitHub Actions

7 ways frontend developers can improve collaboration on UI/UX teams

1. Thinking like a user

2. Speak up early and frequently

3. Leverage productivity tools to stay on track

Framer

FeaturePeek

4. Always be learning

Subscribe to newsletters and RSS feeds

Join online communities

Learn by doing

5. Get feedback often

6. Small design changes; big impact

7. Change your organization

Learn More

It's Not Design Culture Anymore, It's DevOps Culture. And We Should Adjust Accordingly.

How DesignOps Tools Changed the Way We Work

How DevOps Tools are Changing the Way We Work

Learn More

The benefits of on-demand staging environments

What is a staging environment?

How do you deploy to a staging environment?

Why multiple staging environments instead of only one?

Code review won’t block gathering product feedback

Prevent an integration warzone

Lower the barrier for running peers’ code

Avoid redundant code reviews

More opportunities for testing

Avoid environment drift

More stakeholder engagement

Increased developer productivity

Save your company time and money

Single vs. on-demand staging environments

Shorten cross-functional feedback loops with on-demand staging environments

Learn more

Pull requests are the new design handoffs

🛠️ The Collaboration Toolbox: What tools UI/UX teams use to collaborate

🤦‍♀️ The Collaboration Conundrum: What tools do my UI/UX team really need?

↕️ Pull Requests: It’s not just the deployment preview that’s important

🚀 Why the next killer enterprise app will be a developer collaboration tool

Learn More

Why your deployment previews need to be collaborative

🤦‍♀️ Most UI/UX teams are ignoring their biggest communication challenge

💬 Bridging the developer-to-designer collaboration gap

👊 The easiest way for UI/UX teams to review and leave feedback on frontend code

📈 The ultimate collaboration tool for frontend developers

✅ Get Started with FeaturePeek Teams Today

The WFH edition. Our ultimate remote working stack for frontend devs

Remote Working Essentials

The Basics: Team Chat Tools

The Basics: Version Control

The Basics: Video Conferencing

Little-Known Remote Working Tools

Miro: Online Whiteboard

Loom: Video Messaging

FeaturePeek: Deployment Previews

Headspace: Meditation

When To Chat: Timezone Sync