Guaranteeing Customer Satisfaction with Fast-Paced Software Development

The days when software teams needed weeks, or even months, to make changes available to customers are way behind us. Our customers, and customers everywhere, want seamless user experience, and want to see improvements and new features as fast as humanly  possible. Here at SwagUp, we aim to exceed the expectations of all of our clients.

You may be asking, how is this possible? We know that developing software is challenging, and to deliver quality software fast is even harder. However, with our strong team of talented developers, we’ve got that covered!

Amazon Web Services (AWS)

Instead of going for the old, bulky, hard to maintain traditional on-premises servers, we chose to deploy all of our infrastructure in the cloud. Of course, this is awesome to us, the “tech-people,” but how does this benefit you, our customer? Read on to learn more! 

1. Reliability: By deploying our infrastructure to the cloud, we can guarantee that no “act of God”  can interrupt our service (aka, “that guy who was walking by and accidentally unplugged our servers, and now everything is figuratively on fire”). Everything runs through AWS servers, and, as soon as one machine fails, it’s replaced by another, with very short downtime.
2. Scalability and Cost-Effectiveness: Being a relatively small company, paying several thousand dollars upfront to handle a load, which may or may not come, doesn’t make much sense to us. So, using AWS’ infrastructure, we can ensure that we have only the infrastructure necessary to handle the demands of our customers. No more, no less.
3. Security: By running our applications on the AWS cloud, we ensure that all of the infrastructures comply with the latest security standards, so we can then concentrate solely on making your data safe with us.

Jenkins

At SwagUp, we have a lot of developers on our team. Maybe not as many as Google, but definitely more than your average “non-tech company!”  All of our developers are making changes to our code, and creating new versions of our software on a daily basis. If you didn’t believe me when I said that developing software wasn’t easy, trust me when I say that building and deploying that software is no walk in the park either.  A solution to this could be to hire a team whose sole job would be to build and deploy dozens of software versions daily. But, we don’t want to be responsible for ruining any lives, and it’s just counter-productive in the long run, as human error is inevitable. What to do then? Enter Jenkins…

Jenkins is an automation server, and its job is to automate the process that begins with a developer making changes to code in his/her computer, and ends with our software being deployed to the cloud, ready to be used by our customers! Right now, Jenkins is the core of our development process. It allows us to automatically build our software, run tests, and deploy our changes to different environments (more on this later). This process is used to check if changes behave as expected, or if shiny new errors that didn’t appear in the development stage decide to show themselves. Programming can sometimes be more art than science, and programmers are humans, we make mistakes too!

AWS Elastic Beanstalk

As mentioned previously, deploying all new changes by hand is counterproductive, so we cover those using Jenkins. That said, we do need to deploy those changes somewhere. That’s where Elastic Beanstalk comes to play - it provides us with an environment to run our applications. It ensures that our applications are always running properly, as well as providing a centralized interface for our IT team to check on performance.

All of this sounds nice, but having just one environment is too risky. Imagine the amount of headaches that a single error in our final product could cause to the development team? Luckily, Elastic Beanstalk also helps us with that. It allows us to view our application as a higher concept (all of our code versions and common configurations), and allows us to create separate environments where our code would actually run. Then, to keep things organized and to ensure that no bug reaches our customers, we use the Development, Staging, and Production (DSP) Model:

• Development: This is our developers’ playground! Here, changes can be tested with total safety. If something breaks here, who cares? Only we will know, and as long as they are quickly fixed, everything will be fine.
• Staging: Once we’re sure, or as sure as we can be, that the code is functional, we deploy it to the Staging environment. This is basically a copy of our production environment, and we deploy here to make sure that the changes won’t break our currently deployed, user-facing application. If something breaks here it’s not great, but it won’t be the end of the world either.
• Production: This is where our final version resides - this is the environment the customers use when they use or interact with our services. No error should be allowed to continue to production. If something breaks here…. It won’t literally be the end of the world, but I’m pretty sure the development team would prefer “zombie apocalypse” over “error in production” any day of the week...

And more…

This is just a broad picture of what’s happening behind the scenes here at SwagUp, what we are using, and why we use what we do! Of course, there’s so much more to talk about, so many technologies, so many ideas, but that would be an overload of information. Just keep in mind that we make changes all the time. We make mistakes, we learn from them, we do better the next time, and then we repeat the process all over again. This process would not be possible, or at least would be a lot harder, with a different mindset, or if we weren’t using the correct tools we have put in place.