🐞 FIXED

We've resolved reported issues that were causing occasional crashes when, for example:

1. Specify a different brand when doing a pull request:
   • We now allow you to specify a different branch in the base branch field in the pull request modal, when creating a pull request. This means that you are able to select which branch they want to merge their changes into, rather than being restricted to a specific branch such as “main”. This feature can be useful for organizations that use multiple branches for development and testing, as it allows developers to easily collaborate on code changes and merge them into the appropriate branch for deployment. Additionally, it can help to maintain the versioning and history of the Terraform codebase.
2. GCP VPC and Subnet: 
   • They were not containers*. Now, they are… 
   • Containers* in the cloud refers to the use of containerization technology to deploy and manage applications in a cloud computing environment. Containers are a lightweight and portable way to package and deploy applications, and they can be run on a variety of platforms, including Google Cloud. Containers are isolated from one another, which helps to increase security and reduce the chances of conflicts between different applications. 
   • Google Cloud offers a service called Google Kubernetes Engine (GKE) which allows you to easily deploy, scale, and manage containerized applications on the cloud.
   • Google Compute Network (GCN) is a virtual network that allows you to create and manage a network topology for your Google Cloud resources. It allows you to create subnets, firewall rules, and routes to control how your resources communicate with each other and with the internet.
   • Google Compute Subnetwork (GCSN) is a subnet within a GCN that allows you to segment your network into smaller, more manageable pieces. It also enables you to control the IP ranges for resources in a subnet, and apply firewall rules and routes to specific subnets.
3. Variable type not saved:
   • Problem: This bug fix addresses an issue where a new variable is not correctly saving the type information during the creation or modification process. This can cause problems with the functionality of the application, as the type of variable is important for determining how the application should handle and interact with the variable's value.
   • Solution: The fix involves updating the Terraform code that is responsible for handling the creation and modification of variables to properly save the type information. This could involve checking for missing or incorrect type information, and adding code to handle this properly. Additionally, it also involves testing the updated Terraform code to ensure that the bug is resolved and that the new variables are being created and modified correctly with the correct type information. 
4. Custom group TF file broken:
   • Problem: The bug fix addresses an issue with the functionality that retrieves custom group files in Terraform. The bug is related to the fact that when a group starts with 'f' or 't' the retrieval of the custom group file is broken. The issue with the Terraform configuration for the “test” group, as the test.tf file should contain the necessary information for provisioning and managing the infrastructure for that group, but it is empty. 
   • Solution: Create an architecture or a blueprint of the infrastructure using Terraform. Add 3–4 nodes on the design canvas, which are servers or machines that make up the cloud infrastructure. Change the group of 2 of the nodes to “test” group. Now, retrieve the test.tf file, which should contain the Terraform configuration for the “test” group.
5. Scroll through a big output:
   • Problem: The bug fix addresses an issue with the performance of scrolling through the output of the “plan” in Terraform. The bug is causing the scrolling to be slow and unresponsive, with a delay of 2–3 seconds before the update or the next lines are displayed.
   • Solution: We optimized the code that handles the output display and scrolling by reducing the number of updates and unnecessary calculations. We always make sure the data is being loaded and processed efficiently.
6. Import Multiple strings:
   • Problem: The bug fix addresses an issue with the way Brainboard import Terraform code that contains "<<EOF" and "EOF" for a field. The bug causes these characters to be changed into strings which causes issues in the interpretation of the code.
   • Solution: Update the import code to properly handle these characters. We make sure the code that reads and interpret the imported Terraform code is able to handle these characters correctly.
7. Feedback survey:
   • Problem: We noticed that the feedback form brought aggressive prompts to you, builders and cloud architects. 
   • Solution: We've disabled it for now. Please continue to contribute to the Slack community and contact us if any improvements need to be fixed. We generally respond within 6h. 
8. Editing node title:

   

   • Problem: The bug fixes you addresses an issue with the way the editing of the title of a node behaves in Brainboard's canvas. The bug causes the title of the selected node to change when editing the title of a different node that is not selected.
   • Solution: We added a check to verify that the correct node is being edited, or by making sure the system is keeping track of the correct selected node.

🧼 IMPROVED

1. CI/CD Engine: We've just introduced a feature for approval tasks, which allows users to request and receive approval before deploying code changes to a production environment. This can be useful for ensuring that code changes have been reviewed and tested properly before they are deployed to a live environment, and can help to prevent errors or issues that could negatively impact the performance or functionality of the system.
2. Import: We continue to improve the import feature. This week, we've focused on database use case. Now, you can import schema and documentation. A schema is the structure of the database and the rules on how the data should be organized, while a document is a single unit of data stored within the database.
3. Deleting cloud architectures: When soft-deleting cloud architectures, we now soft delete all related objects including workflow(s), pipelines, jobs, deployments, git integrations, and terraform settings.

📆 Replay: Understand CI/CD strategies & Best Practices 

• 0:02:20 CI/CD Day
• 0:04:40 CI/CD in Application world 
• 0:07:00 CI/CD for the app  
• 0:13:47 IaC Best practices 
• 0:20:00 Application vs. Infrastructure 
• 0:28:00 IaC languages 
• 0:34:40 Existing solutions 
• 0:38:40 Commonalities & Challenges
• 0:42:10 What is expected from a CI/CD solution 
• 0:48:10 Some of useful open-source tools 
• 0:52:00 CI/CD Best practices 
• 0:57:40 Successful Implementation 
• 1:05:20 Brainboard CI/CD Engine—demo tour 
• 1:05:50 Design your first CI/CD workflow visually 
• 1:09:00 CI/CD outputs 
• 1:10:40 Create a CI/CD pipeline template

🐞 FIXED

We've resolved reported issues that were causing occasional crashes when, for example:

1. Storage Container already exists issue:
   • Problem: When creating a new Storage Container in Brainboard, if the container already exists in AWS or Azure, the application would fail.
   • Solution: We have implemented a check that verifies if the container already exists in the specified cloud provider before attempting to create it. If the container already exists, Brainboard will no longer fail and will instead display a message indicating that the container already exists.
2. Git Personal Token Editing Error:
   • Problem: When editing only one field in the Git Personal Token, an error occurred and the changes were not saved.
   • Solution: We have identified the problem and fixed the issue with the Git Personal Token editing process. Users should now be able to edit any field in the token without encountering errors.
3. Terraform Block Removal:
   • Problem: When importing Terraform files, such as backend.tf that contains a Terraform block and many providers block, the Terraform block was automatically removed.
   • Solution: We have identified the problem and fixed the issue with the Terraform block removal during import. The Terraform block should now be retained and not removed during the import process.
4. Map variable syntax issue:
   • Problem: When importing a Terraform file that contains a map as the type of variable and the values are defined in terraform.tfvars, the values were changed and replaced with an invalid Terraform syntax, causing the plan to fail,
   • Solution: We have identified the problem and fixed the issue with the map variable syntax. The values should now be imported correctly and retain their original syntax.
5. Validation Block Import:
   • Problem: When importing from Git or files, for example, a Terraform code that contains a validation block, the variables validation block was not imported in Brainboard.
   • Solution: We have identified the problem and fixed the issue with the validation block import. The variables validation block should now be imported correctly and be visible in Brainboard.
6. Terraform Variables Modal:
   • Problem: The Terraform variable modal was changing every time it was opened or when doing a pull request. This caused confusion and made it difficult to track changes.
   • Solution: We have made changes to the Terraform variable modal, so it will no longer change every time it is opened or when doing a pull request. This will make it easier to track changes and manage variables.
7. Default Terraform Code File:
   • Problem: The default Terraform code file was main.tf, but it was causing confusion when working on a different resource file.
   • Solution: We have changed the default Terraform code file to be the resource file that the user is currently working on. This will make it easier to manage multiple resource files and keep track of changes.

🧼 IMPROVED

We've made some performance enhancements to the:

1. Terraform Code Generation: We have made significant improvements to its Terraform code automatic generation process, making it 2x faster and more reliable. By optimizing the code generation algorithms, Brainboard has made it possible to generate Terraform code from diagrams in a fraction of the time it used to take. Additionally, the code generated is more reliable and maintainable for the long term. The generated code is now more readable and easier to understand, making it simple to read changes and updates. The new generation process also includes a new error checking feature, which identifies and corrects errors before the code is generated, ensuring that the generated code is error-free. Overall, these improvements make Brainboard's Terraform code generation process one of the best in the industry, providing users with a fast, reliable, and maintainable solution.
2. CI/CD Plugins: We have added more available arguments and options for CI/CD plugins. This will give users more flexibility and control when integrating with their CI/CD pipeline.

📆 Thursday, January 24th, 2022

• The current state of CI/CD solutions and how they work
• The challenges associated with it and how they impact your process
• What are the best practices that apply to the infrastructure automation
• What changes are needed to have a successful implementation
• The most important part: what is expected from a CI/CD solution that is cloud infrastructure specific

Before

Now

About

1. Collaborate effectively with team members: PR/MR provide a way for team members to propose changes to the infrastructure codebase and review and discuss them with other team members before merging them into the main branch. This allows for better collaboration and communication within the team.
2. Implement code review and testing processes: PR/MR provides a way to implement a code review process, where other team members review changes to the infrastructure codebase before being merged. This can help identify and fix bugs and issues before they are deployed to production.
3. Track changes to the infrastructure codebase: PR/MR provides a way to track changes to the codebase, including who made the change and why making it easier to understand how the infrastructure has evolved.
4. Rollback changes: PR/MR provides a way to roll back changes to the infrastructure codebase if something goes wrong. This can be done by reverting the merge commit or using version control tools like Git to revert specific changes.
5. Isolate changes: PR/MR provides a way to isolate changes, meaning that changes are committed and tested in a separate branch before merging into the main branch. This allows for keeping the main branch stable and ready to deploy at all times.
6. Implement automated testing and integration: PR/MR provides a way to implement an automated testing and integration process. This can be done by integrating the VCS with a continuous integration and deployment tool, which can run automated tests and deploy changes to different environments.

• One of the improvements is that it eliminates missing fields when configuring specific cloud resources. You no longer have to worry about missing important information when setting up your cloud infrastructure. 
• The ID card allows for multi-block everywhere, allowing for better customization options. This can be achieved by using hardcode, a powerful tool for making changes to the infrastructure. 

1. Using the "depends_on" argument in resource blocks allows you to specify that a resource depends on another resource and must be created after it.
2. Using the "${resource.name.attribute}" syntax allows you to reference the attributes of one resource in the configuration of another resource.
3. Using the "data" blocks to retrieve information from external resources allows you to retrieve information from existing resources and use it to configure new resources.
4. Terraform modules allow you to group resources and reuse them across multiple configurations. This is a way to organize your resources and share them with others.
5. Using Terraform's variables: Terraform variables can store resource information and reference it in multiple places in your configuration.

Latest Terraform Providers' versions:  

In Brainboard, this applied for all cloud providers supported (Azure, OCI, GCP, Scaleway)

1. Use variables to define the regions you want to deploy your infrastructure in: By using Terraform variables; you can specify which regions you want to deploy your infrastructure in and make it easy to change or add regions in the future.
2. Use variables to define the specific resources in each region: By using Terraform variables, you can specify the specific resources you want to deploy in each region. This allows you to create different resource configurations for different regions easily.
3. Use variables to define the AMI ID: By using Terraform variables, you can specify the AMI ID (Amazon Machine Image) you want to use in each region. This allows you to use different AMIs for different regions.
4. Use variables to define the subnets and availability zones: By using Terraform variables, you can specify the subnets and availability zones that you want to use in each region. This allows you to use different subnets and availability zones for different regions.
5. Use variables to define the security group: Terraform variables can specify the security group you want to use in each region. This allows you to use different security groups for different regions.

variable "region" {
  default = "us-west-2"
}

resource "aws_instance" "example" {
  ami           = var.ami
  instance_type = "t2.micro"
  region        = var.region
}

Improve the error handling in the CI/CD (Continuous Integration/Continuous Deployment) engine of Brainboard. Specifically, the improvement is related to the handling of errors that occur during the use of web sockets.

*Web sockets are a technology that allows for real-time, two-way communication between a client and a server over a single, long-lived connection. In the context of CI/CD, web sockets may facilitate communication between Brainboard's CI/CD engine and other system components, such as the version control repository or the deployment pipeline.

*Single tenant refers to a software as a service (SaaS) solution where each customer or client has their dedicated instance of the software running on a separate infrastructure. This contrasts with a multi-tenant SaaS solution, where multiple customers or clients share the same software instance, running on a shared infrastructure.


In a single-tenant SaaS solution, the customer's data and configuration are isolated from other customers and not shared with any other organization. This provides a higher level of security, compliance, and customization. Customers have more control over their data, and the software can be tailored to the customer's specific needs.


Single-tenant SaaS solutions are typically used by larger organizations with more stringent security and compliance requirements or organizations requiring a high level of customization. They may also be used by organizations with sensitive data that they do not want to share with other organizations.


It's important to note that Single tenant solutions are often more expensive than multi-tenant solutions because the hardware and infrastructure costs are spread across fewer customers. Additionally, because each customer requires its own infrastructure, there are more operational costs to manage and maintain the different instances.

*The ID cards would represent different cloud resources, such as virtual machines, load balancers, and storage volumes. By dragging and dropping these ID cards onto a canvas, users could quickly and easily design their desired cloud infrastructure.

Once the diagram is designed, it would also be actionable, meaning that the user could deploy their cloud infrastructure with a single click. Brainboard would then automatically provision and configure the necessary resources based on the ID cards that were used in the design.

Brainboard greatly simplify the process of designing and deploying cloud infrastructure, as it would provide users with a visual, intuitive way to work with the resources. Additionally, the use of ID cards could also enable users to easily share and reuse their cloud infrastructure designs with others.

Before

1. Reusability: Modules allow you to group resources and reuse them across multiple configurations. This can significantly reduce the code you need to write and maintain.
2. Organization: Modules provide a way to organize your resources and make your Terraform configurations more readable and maintainable.
3. Versioning: Modules can be versioned, which allows you to track changes and roll back to a specific version if needed.
4. Collaboration: Modules can be shared and used as a building block for other people's configurations. This allows for better collaboration within a team or community.
5. Abstracting complexity: Modules can help abstract away complexity by breaking down large configurations into smaller, more manageable pieces.
6. Better testing: By using modules, you can quickly test a specific part of your infrastructure without affecting other parts.
7. Scalability: Modules can help to scale your infrastructure more efficiently. They can be used to create reusable and composable infrastructure patterns which can be used across different environments.
8. Simplifying the management: Modules help to simplify the management of infrastructure by breaking down complex infrastructure into smaller, more manageable components.

Import your Terraform modules on Brainboard.

You can: 

• Visually design and orchestrate your deployment workflows without a single line of code.
• Connect your automation ecosystem with OPA, Infracost, Checkov, or Terrascan…
• Centralize your custom automation strategies and remote-run deployments.
• Execute, optimize and manage workflows for successful outputs.
• One of the biggest added values in terms of deployment is that Brainboard manages the upgrades and maintenance of the supported plugins: Infracost, OPA…

Brainboard’s CICD workflow designer is out now. Discover it for free →

We listened to your requests and just added OCI (Oracle Cloud Infrastructure) to Brainboard, your one-and-only IaC solution! 

• You can use Terraform to interact with Oracle Cloud Infrastructure resources
• You can visually build your OCI cloud infrastructure and deploy it with ease
• You can import any existing OCI-based repo, public and private onto Brainboard
• You can convert all your OCI cloud infrastructures into reusable templates.

* tfvars files are Terraform configuration files that store variables for a Terraform configuration. They typically have the file extension .tfvars and are used to set values for variables that are used in Terraform configuration files. These files allow you to store sensitive information like credentials and other sensitive data, which you can use in your Terraform configuration, but without having to hard-code them in your .tf files.

Introducing Import Azure

• The location/Region field has been fixed to ensure that it accurately reflects the real value.
• We have fixed an issue where variables locals were not retained during the cloning process.
• The reminder form has been fixed to ensure proper functionality.
• The custom code field is now fully usable, as it was previously causing issues.
• The architecture cloning process now also retains locals values.
• We have resolved an issue where the deletion of modules from the catalog was not working as expected.

• As an individual contributor, you can add personal git tokens for any supported git provider - Azure DevOps, Gitlab, Bitbucket - and specify the scope of the creds and have visibility on where they are used.
• As the owner of the organization, you can add Github app integration and users perform git actions based on their authorization on Github.

• The Git credentials of your organizations are assigned to the owner of the organization. So you need to add your personal token in order to do pull requests. 
• If you use GitHub, there is nothing to do. Your pull requests work as before. 

• Pull requests: Choose the git provider to use from the supported ones - Azure DevOps, Gitlab, Bitbucket, GitHub, and add the description, project, folder, and base branch within the service.
• Modules: You can choose which git credentials you want to use to import your private modules and use them.
• Generate your diagram from the terraform code: Choose the git credentials you want to use and import your existing terraform code.

• Fixed: When I delete my current architecture, the interface freezes / infinite loop with error in console
• Fixed: When I add an Azure virtual network for e.g. and I remove a chip from tags, the interface resets, the code generated is completely broken and I have no way to open the resource again to fix it.
• Fixed: We can’t change the selected TF file to another one (other group tf file, variables, outputs, …)
• Fixed: When a user configure a block (set) then deletes all the value the block is generated empty. 
• Fixed: Subnet IDs double added
• Fixed: Automatically generate the connectors between resources when I reference an existing resource.
• Fixed: when I connect, it shows the owner as an extra user
• Fixed: With some attribute type like SelectList (array), changes do not trigger the TF code refresh
• Fixed: Sign up page on Safari browser 
• Fixed: In the README modal, the save button doesn’t work at all, so if I write content it is automatically saved and there is no need for this button.

*Keycloak is an open-source identity and access management solution. It is designed to provide a centralized location for managing user authentication and authorization. Keycloak provides features such as Single Sign-On (SSO), user management, and access control for applications and services.

• You have the ability to add blocks easily
• You have the ability to use multiple time the same block 
• You have the ability to upload files in the idcard
• ALL lifecycle are supported

• Split nodes into different files
• Import tfstate now is automatic and part of importing files
• Remove credentials in the module source URL -> security improvement
• Clone templates in the same architecture
• Fix graphical bugs to make the user experience enjoyable
• Allow emoji / any char in names (architecture, env, team, ...)

• Select group when selecting file
• Select the right file when opening the IDcard
• Group name validation improved

• Import module
• Import from GitHub/GitLab/…
• Everywhere else we support GitHub/AzureDevops

• In GCP, Terraform tags are used to add metadata to resources such as virtual machines, disk, and networks. These tags can be used to identify, organize and manage resources within GCP. For example, you can use tags to organize resources by environment, application, or project, and you can also use tags to identify resources for billing and cost management.
• In AWS, tags are used similarly to GCP, but they are referred to as resource tags. AWS tags provide a way to organize and categorize resources within an AWS account.

*Terraform deployment is the process of creating, updating and deleting resources in an infrastructure, using Terraform HashiCorp Configuration Language (HCL) and Terraform API.

When you run terraform plan command, it compares the current state of infrastructure with the desired state, defined in the Terraform code, and it shows the changes that will be made to the infrastructure.

When you run terraform apply command, it applies the changes, defined in the plan to the infrastructure.

When you run terraform destroy command, it removes all resources, defined in the Terraform code from the infrastructure.

During this process, Terraform keeps track of the current state of the infrastructure in a state file, which is usually stored in a remote backend, such as AWS S3, and it can also be stored in a local file.

*In Terraform, a local is a way to assign a value to a variable, and it's only accessible within the same module where it's defined. A local variable can't be accessed outside of the module where it's defined. It can be used to store temporary values that are used within a module and it's not exposed to other modules.

• import module
• import from GitHub/GitLab/…
• Everywhere else we support GitHub/AzureDevops

AWS GovCloud (US-West) and AWS GovCloud (US-East) are regions that are specifically designed to host sensitive data and regulated workloads in the cloud, and they are isolated to the US Government's infrastructure. These regions provide a high level of security and compliance.

Examples of the regions include:

• us-gov-east-1

• us-gov-west-1

*Frontend reload system refers to a technology that allows for automatic updating of the front-end (client-side) of a web application. It is used to ensure that users always have the most recent version of the application, without the need for manual updates.

1. Add a module
2. Edit the ResourceName
3. The change is applied and the new ResourceName just appeared in the code

• The locals part is added at the end of the variables table 
• Only name, scope, value, and description are used and visible 
• The description should be a comment before the local in the generated Terraform file

*Bitbucket is a Git-based source code repository hosting service owned by Atlassian. It allows users to store, manage, and collaborate on their source code projects, using Git as the version control system. Bitbucket supports both public and private repositories, and provides features such as pull requests, code review, and issue tracking to help teams collaborate on code development.

• Ask a mandatory team to invite member
• The default team is Admin on the default project
• UX improved for project create/update 

• Azure: block settings + feature block page
• AWS: block settings
• Hashicorp/vault: block settings (as you can see the address is required and not optional)

This feature is mainly for users that won’t deploy within Brainboard but already have their git and some TF provider settings.

1. Design
2. Design / Code vertical 
3. Design / Code horizontal 
4. Code  

• AWS 4.8.0 (Upgrade to v4 guide)
• Azure 3.0.2 (Upgrade to 3.0 guide)
• Google 4.15.0
• Scaleway 2.2.0

Reverse Terraform is a feature of Brainboard that allows users to automatically generate Terraform diagrams and code from an existing Terraform file, a public or private repository, and connect to their cloud provider's credentials. This feature enables users to create visual representations of their infrastructure and quickly understand the relationships between resources, as well as generate Terraform code for those resources, making it easier to manage and maintain their infrastructure. Additionally, by connecting to cloud provider credentials, Brainboard can also pull in information about existing resources and use that to generate the Terraform code, allowing users to easily import their existing infrastructure into Terraform.

• Private Repositories (Only GitHub): This fix allows users to connect to their private GitHub repositories and import their Terraform code. This is useful for users who want to keep their infrastructure code private and only accessible to authorized users.
• Supports count, timeouts, depends_on (add connector with the dedicated connector.link.type): This fix enables the tool to support count, timeouts, and depends_on Terraform resources, which are used to create multiple instances of a resource, set timeouts for resources, and specify dependencies between resources. The tool also allows users to add connectors with the dedicated connector.link.type.
• Supports terraform functions (like format, substr, ...), string interpolation (like “aaa$[var.test]”): This fix enables the tool to support Terraform functions, such as format and substr, and string interpolation. Terraform functions are used to perform various operations on strings and variables, while string interpolation allows users to include variables within strings.
• Some resource attributes not parsed: This refers to an issue where some resource attributes were not being parsed correctly by the tool. This fix addresses this issue, ensuring that all resource attributes are parsed correctly.
• Create module idcard on the fly: This fix allows users to create module idcards on the fly. A module idcard is a summary of a module's inputs, outputs, and resources. This allows users to quickly understand the purpose and structure of a module without having to examine its code.
• Import code with module fails: bad source, no version: This refers to an issue where importing code with modules would fail if the source or version was not specified correctly. This fix addresses this issue, allowing users to import code with modules correctly.
• Git root/base repo URL doesn't work: This refers to an issue where the git root or base repo URL was not working correctly. This fix addresses this issue, ensuring that the git root/base repo URL works correctly.
• Support EOF in resource attribute: This fix enables the tool to support EOF in resource attribute. EOF, short for End-of-file, is a control code used to indicate the end of a file or stream. This fix allows the tool to correctly handle EOF in the resource attribute.

Migrate your cloud infrastructure on Brainboard for a better process standardization. 

• A common resource shared between multiple architecture
• For security reason (read-only access)
• Managed by another team