Javier Vázquez
Salesforce Developer

Development

CI with Salesforce – part 1: Where we were at and where we should

April 10, 2019

April 10, 2019 by Javier Vázquez

When I started to think about this post, it was not easy for me to find a clear way to explain it. This has been a long and hard project, involving a lot of teams and processes, and explaining what we have now and why, could be complex without previous knowledge of our flows, methodologies, technologies and general context. This is the reason why I decided to explain how our deployment flow has evolved with the time by writing a series of posts to explain individually every step we made and all the problems we encountered along the way.

In this first article, I will share with you what was our starting point. How we were working and why we decided to improve this flow.

In the very early stage of our Salesforce team here in Ebury, the team was formed only by a couple of developers and a QA engineer. It was an easier time where all the developments were agreed by the full team; each member knew what their colleagues were working on, and the conflicts were very few and quick and easy to resolve.

Every developer had their own sandbox (or several ones in case we were working in stories related to different projects) and, when the development was finished and the code review approved, the code was moved into DEV sandbox (the one used for testing) using changesets. At the same time, every story was developed in a separate branch and, after PR approval, it was merged into the dev branch. You can realise we are using VCS only for code review and for auditing, but not for deployments.

OK, let’s stop here and think why this worked and why this cannot work at scale.

It is not a bad flow, keeping different sandboxes for development and other ones for testing and staging, as you can see in the next picture:

Let’s enumerate the different problems we faced:

  • Repository is not the source of truth. This is probably the key point for almost all of our problems, and the most important difference between Salesforce development and the development in any other technology. We cannot trust that the code in the repository is accurate to the orgs, and that is something we cannot allow.
  • Changesets are painful. If you are reading this article surely you have worked with changesets at some point. You already know how manual and slow it can be adding changesets, uploading them into a different sandbox (sometimes this can take reeeeally long), deploying, checking something is missing, going back to the source sandbox, cloning it, deploying it again, and all kinds of painful stuff. This can work for little changesets, but when you are deploying hundreds of components, this is worthless.
  • Resolving conflicts. What happens if you are modifying some file which is also modified by another developer? We have two options: conflicts or not. If we have conflicts, the developer who faced them has to resolve them, compile the files again in the sandbox, clone the changeset and deploy it again. It could look like not much work… but the problem now is that we have code in our platform which is not related to us. If that other story had new fields, objects, and so, everything has to be created also in your org to be able to continue. And what happens if we have no conflicts? This could be the happy path, but is not, and here is the next point: code overwriting.

Resolving pull requests...

  • Code overwriting. You just finished your development, the PR is ok and you merged it. Great! Let’s deploy it into dev sandbox, it’s QA time… or not. There is a possibility that when you deployed your changeset into dev, if you have modified the same file another developer did, and as you don’t have those changes in your org (you had no conflicts in the PR, how could you know?), you have deployed a different version of that file and the changes the developer did are now no longer there. We have several workarounds for this, but the communication is the most important point here. If you know what the other developer is doing, mainly because you are reviewing all their changes, then you can anticipate to these conflicts. However, in my experience this step was commonly missed.
  • Dependencies: What happens if you pull some dev changes into your code to avoid overwriting but later your story is ready before the other one? You cannot deploy your changeset! This is because your changeset also has changes which are not in the target org, so your story is ready to be deployed into staging/prod, but the deployment is stopped until the other story is also finished. This is frustrating.
  • Automation: Changesets are not considered for CI, and there is no easy way to use them from the command line.
  • File removal: You cannot remove files using changesets, so you have to search for alternative ways to do it.

Probably I could add some more issues to this list, but I have focused on the main ones.Before finishing: if you are thinking about how great changesets are, I don’t want to wake you from your dream. I know changesets are great for non-developers or people starting in Salesforce, they are easy to use and to understand, and you can do everything through a UI. However, since the moment you start working in more complex projects, involving hundreds of files, dozens of developers, multiple phases and integration with external systems, you need to (must) think about taking a step forward into the CI world.

I hope I’ve been clear enough conveying the problems we had and the reasons for a change. In the next post, we will talk about the different possibilities we were analysing and take a detailed look at the direction we chose (spoiler alert: sfdx).

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Sergio Robles
Devops Team

Development, DevOps, LABS

Terragrunt : Terraform the easy way

March 12, 2019

March 12, 2019 by Sergio Robles

We are using Terraform to configure our Infrastructure as Code in AWS and we used it with Terragrunt from the first day.

What is Terragrunt? the official definition

“… is a thin wrap for Terraform that provides additional tools to maintain your Terraform DRY configurations, work with multiple Terraform modules, and manage the remote state.”  (read more)

We have found Terragrunt very useful, it allows us to configure the remote state, locking, additional arguments, etc. depending on the configuration of your terraform.tfvars file.

The best features of Terragrunt for us are:

Read more

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Sergio Robles
Devops Team

DevOps, Events

DockerCon EU 18

March 12, 2019

March 12, 2019 by Sergio Robles

On December of 2018, the Ebury team attended DockerCon EU.

DockerCon Europe describes itself as “a 2.5 day technology conference, where customers and community come to learn, share and connect with each other. Attendees are a mix of developers, systems admins, architects, and IT decision makers —from beginner to intermediate, and advanced users—  who are all looking to level up their skills and go home inspired and ready to invest and implement their containerization strategies” and that is exactly what we wanted to get out of it.

Read more

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Juan Manuel Pérez
Quality Assurance

Agile

Tech Culture: Teams, Tribes and Pirates

March 8, 2019

March 8, 2019 by Juan Manuel Pérez

Tech Culture: Teams, Tribes and Pirates

Welcome to this biology post, because in a high-level, I’m going to share part of our Agile DNA. We will cover 3 ways we interact with other Tech colleagues:

  • Teams
  • Tribes
  • Pirates

Teams

Our Scrum Master are going to explain this information in other post but Teams at Ebury are responsible of few microservices (API, Faster Payment, SEPA, Website …) or a larger application (Back Office System, Salesforce, Ebury Online…). These cross-functional groups from 4 to 8 people are aligned with the business roadmap and goals for the next few months.

Read more

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Agile

Our Agile Process

February 14, 2019

February 14, 2019 by Fernando Lopez

At Ebury, all of our development teams use the Agile Scrum framework, so we thought it would be interesting to share a little bit about what goes on under the hood.

Scrum framework

Scrum is used by over 12 million people around the world for products big and small. It all starts with a Product Owner who represents customers and other stakeholders. The Product Owner drives the Product Backlog, a prioritized dynamic list of all the work that might be needed for the product.

Work is done by a self-organizing Development Team during the Sprint, a period of time between one and four weeks.

During Sprint Planning, based on the Sprint goal, the Sprint Backlog is populated. Once a day, the Development Team meets for 15 minutes for the Daily Scrum to inspect and adapt their progress toward the Sprint goal and to surface dependencies or impediments.

So, who makes sure that the Scrum Framework is understood and enacted? the Scrum Master. The Scrum Master is the servant leader of the Scrum Team and helps everyone understand Scrum theory, practices and rules. As the team works towards the Sprint goal, iterative delivery and feedback allow us to adapt our next steps. To improve transparency, the product increment can be released continuously during the Sprint.

At the end of the Sprint, the Scrum Team invites the stakeholders to the Sprint Review, where they collectively inspect the results. After the Sprint Review, the Scrum Team runs a Sprint Retrospective where they evaluate how they worked and build a plan for how to improve.

Scrum at a glance
Scrum at a glance

Read more

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Data science, Design/UX

Visualizing User Experience Data with Google Data Studio (Part II)

January 21, 2019

January 21, 2019 by Carmel Hassan

In our previous article ‘Visualizing User Experience Data, we defined a framework to measure the User Experience of a product. In this article, we want to share how we can use Google Data Studio to visualise those metrics and facilitate the decision making during the design process.

Data Studio

Data Studio is a free tool offered by Google that allows you to create interactive dashboards and reports with data visualizations using multiple sources of data.

Data Studio user interface is pretty intuitive, however, there are two key concepts you need to manage to get started:

  1. Data sources let you connect data sets. This is the first thing you have to do before adding charts to reports.
  2. Reports let you visualise data. You have to select one or many data sources to feed data displays. Reports can be shared, interacted and exported.

Starting a new report is as simple as clicking on a button. If you don’t want to start from scratch, you can follow their tutorial that explains how to work with reports step-by-step.

datastudio user interface
Data Studio User Interface

Read more

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Development

The Fin and the Tech

January 17, 2019

January 17, 2019 by Victor Tuson Palau

We often talk about Ebury being a disruptive Fintech company. Today I wanted to go into more detail about what makes Ebury a Financial and Technology company.

FINtech

Ebury’s core business is foreign currency exchange (Forex), and we focus on the enterprise segment of the market. To better illustrate what we do, let’s take as an example a made-up European toy company, which we will call TOYSA.

Read more

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Design/UX

Visualizing User Experience Data (Part I)

January 14, 2019

January 14, 2019 by Carmel Hassan

Ebury Online is a platform that allows users to do international payments quickly, securely and efficiently. Using data analytics it’s an important part of Ebury’s design process.

We, as product designers, need to have a great understanding of data in order to make informed decisions that will impact both on the business and the user experience (UX).

Services like Google Analytics or Hotjar facilitate the exploration and understanding of how websites are navigated. However, in 2017 and 2018, only 1 in 3 designer-related roles use any experience monitoring tool.

At Ebury, we think that data can certainly help us to find answers to questions like ‘who is our audience?’, ‘what do they do?’, ‘how do they perceive and experience the product?’ and ‘how good is that for the business?’.

As shown in the image below, data is collected directly from our Online platform using the huha.js library, sent through Segment and shared to different end-points, which will facilitate smart analytics.

UX Data Tools
Tool framework to collect UX metrics

Read more

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Design/UX, Events

The best of Generate Conference – 2018

November 12, 2018

November 12, 2018 by Carmel Hassan

Last month, the Ebury team attended Generate, a conference dedicated to designers who are looking to improve the user experience (UX) of their websites. We’ll be talking through what we learned, how we’ll be applying our new knowledge to our UX, but most importantly, what you can take away to apply yourself.

The opening talk was presented by Sarah Parmenter who spoke about the importance of digital marketing strategies that can be easily applied by anyone. Parmenter shared key rules that can be applied today to help decide the best media tool to distribute your company’s message: First, think about your Product, then the client Experience, and then the Story. Only then, you can choose the right media outlet.

Our tip for you: If you decide to do a video, make sure you include subtitles, as 85% of all videos are played without sound.

Do you struggle to get your videos noticed? Try Hashtagify to find the best hashtags to get your content noticed.

The closing talk was presented by Sara Soueidan, a front-end UI developer who talked through how cascading style sheets (CSS) and scalable vector graphics (SVG) can be used for better usability and accessibility. One takeaway we gathered from this was to make sure that you integrate these inclusive design practices as part of your natural design and development process.

While CodePen’s senior software engineer Cassidy Williams impressed attendees by coding an image chosen at random found on Dribbble, designer and developer, Ricardo Cabello, demoed Three.js library to demonstrate how you can create WebVR interfaces with the library available on that platform.

UX consultant Trine Falbe talked through the importance of ethics when designing, highlighting the importance of how the data generated by users is looked after. In an age where data is the new oil, this is to consider for data-driven teams.  

Probably one of the most interesting talks of the day was presented by Andrew Godfrey, Senior Design Specialist at Invision, on Design Systems fails. Godfrey exposed some of the goals a successful design system has, such as:

  • Improved consistency
  • Efficient time on task
  • Efficiency reuse
  • Inclusive design (accessibility)
  • Reduction of defects
  • Improved UX
  • Strong design community

Godfrey also highlighted common failures that need to — and can easily — be avoided, such as:

  • Low adoption by internal staff
  • Low understanding by internal staff
  • Mismanaged content
  • Scale system difficulty
  • Lack of support
  • Missing the bigger picture (not just in UI components)
    • Lack of style guides
    • Unclear visual components
    • Unclear standards
    • Accessibility
    • Animation
    • Information architecture

Godfrey advocates considering Design Systems as a core project inside the business, which means adopting processes such as:

  • A plan, strategy, and process
  • A roadmap and priorities
  • Scaling up when validating
  • Incorporating ways of measuring and sharing success
  • Creating prototypes that can be validated
  • Assigning a ‘person of expertise’, that knows the system well
  • Effectively calculating design debt

 

For us at Ebury, Design Systems are one of the key tools to create and maintain a good user experience across all of our services. This is the key principle behind Ebury Chameleon and the reason why we’ll continue investing and improving our processes to ensure high-quality products and services.

Share on Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn