Continuous Integration / Continuous Deployment

We are problem solvers at heart and driven by an enterprising and innovative spirit.

Our utilization of the latest technology and continuous integration enables us to solve problems quickly and build great software.

What is Continuous Integration?

Continuous integration (CI) is the practice of automating the integration of code changes from multiple developers into a single software project. It’s a primary DevOps best practice, allowing developers to frequently merge code changes into a central repository where builds and tests then run.

What is Continuous Deployment?

With Continuous deployment (CD), every change must pass all stages of our production pipeline to be released to our customers. Any failed test will prevent a new change from being deployed to production. 

Continuous deployment is an excellent way to accelerate the feedback loop with our customers and take pressure off the development team as there isn’t a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they’ve finished working on it.

Things to know first:

Raamp currently has 4 different deployment environments:

  1. Development:
    This is an instance that developers use before sending it out to QA.
  2. QA:
    This is a sandbox of sorts, the database is mirrored from production and is synced one-way, meaning that you can’t hurt anything in production if you mess up. We use this instance to give our users a safe place if they need to try something new and it is the last stage before moving to production. The accountant users love this place because they can try out an idea and see how something might affect their reports or invoices.
  3. Production
    This is the Raamp application that our users know and love, it has an isolated database with a group of services that is also isolated from all other environments. Raamp production has its own pipeline that automatically gets updated once code has passed quality assurance and testing. 
  4. Demo:
    If you are a Raamp user you probably have seen this environment and didn’t realize it. This is a stand-alone instance where we demo features of Raamp.

So, knowing that we have 4 different environments, consider the old way of deploying an application manually. For each environment the Raamp development team would have to deploy each solution to each environment. Code changes, authorization keys, even links to other sites would all need to be deployed separately. That means once a developer makes a change it would take a few hours to get the code to Development and then a few more to get it to QA, then if it passes QA it will take a few more hours to compile everything locally and deploy it to Production and the Demo site. If you have multiple managers or developers who can deploy, every computer that can deploy code will need to be configured exactly the same, if there are differences there can be many negative consequences.

Simply writing the above stressed me out. Here comes the continuous integration and deployment approach.

Continuous Integration in Raamp.

Raamp uses GIT to manage our code, meaning we can track, modify, and constantly adapt to learn from our past. It also means that all of our developers can work on different tasks without conflicting with others’ work.

Once a Developer finishes a task, he submits a pull request (code he thinks is ready for production).

The above are real pull requests from a couple of developers. The great thing about operating under GIT is that developers can always be active, they don’t need to stop new tasks while waiting on approval of their previous tasks. Likewise, management can review tasks based on importance rather than on completion dates. Once the code it approved it is added to a pipeline that tests the code and makes sure all projects and applications compile and pass automated testing.

Continuous Deployment in Raamp

If there is a feature or project a Raamp user needs, we can deploy resources quickly. If we find a bug or issue, we can usually get it resolved in a matter of hours not weeks because our developers can simply start a new task, work out the issue, and then submit a pull request. 

Once the pull request is approved by management it triggers a complex set of tasks that deploys the apps to development and QA. Once the feature or multiple features pass QA another pull-request is started asking for the code to be merged with the Production branch. The code is approved and then Raamp and the Raamp demo site are concurrently updated. 

Fast, Safe, Impressive

The developers don’t need to worry about setting up a specific computer to build and compile the Raamp applications, they just write code, test code, and impress our users. We have a dedicated development team that can write mobile apps, customize reports and automate your existing operations. We are more than just a property management software; we are partners with our users helping them not only with a great software but with custom software solutions. 

As we continue to grow and innovate our users must still come first and by implementing CI/CD pipelines we are able to focus on that goal. 

Do you have a project or app your company needs developed? With our expertise in #PropTech; out development team can help you develop and launch your project with confidence. 

You may also like

Exercising an option under ASC 842, Deciding if you should exercise an option

Am I Reasonably Certain to Exercise an Option under ASC-842? How to Know

Exercising an option under ASC 842, which is the accounting standard for lease accounting in the United States, depends on various factors. ASC 842 requires organizations to recognize lease assets and liabilities on the balance sheet. This includes guidance on how to account for these leases. How can you be reasonably certain to exercise an option?

Read More »